Maven中scope标签详解

概述

scope元素的作用：控制 dependency 元素的使用范围。通俗的讲，就是控制 Jar 包在哪些范围被加载和使用。具体值如下：

• compile：默认值。表示被依赖项目需要参与当前项目的编译、测试、打包、运行，是一个比较强的依赖。
• test：依赖项目仅仅参与测试相关的工作。包括测试代码的编译和执行，不会被打包，例如：junit。
• runtime：表示被依赖项目无需参与项目的编译，不过参与后期的测试、打包、运行。与compile相比，跳过了编译。例如JDBC驱动，适用运行和测试阶段。
• provided：理论上可以参与编译，测试等周期，但不被打包，也不会参与运行，因为其他的依赖会提供。相比于compile，打包阶段做了exclude操作。
• system：和provided相同。不过被依赖项不会从maven仓库下载，而是从本地文件系统拿。需要添加systemPath的属性来定义路径。一般用于引用外部Jar包。
• import：它只使用在<dependencyManagement>中，表示从其它的pom文件导入dependency的配置。

作用域scope	编译	测试	运行	打包	实例
compile					Spring-core
test					junit
runtime					JDBC
provided					Sevlet api
system

compile（默认）

含义：compile 是默认值，如果没有指定 scope 值，该元素的默认值为 compile。被依赖项目需要参与到当前项目的编译，测试，打包，运行等阶段。打包的时候通常会包含被依赖项目。

provided

含义：被依赖项目理论上可以参与编译、测试、运行等阶段，相当于compile，但是再打包阶段做了exclude的动作。

例：开发web的时候，需要用到servlet-api，于是在pom.xml中添加依赖：

<dependency>
    <groupId>javax.servletgroupId>
    <artifactId>servlet-apiartifactId>
    <version>3.0-alpha-1version>
dependency>

通过插件启动tomcat的时候，报错，里面有一段是这样的：

Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of org/apache/catalina/loader/WebappClassLoader) previously initiated loading for a different type with name "javax/servlet/ServletContext"
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:355)

产生的原因是：tomcat中也有servlet-api包，这样，发生了冲突。

解决方法：添加provided，因为provided表明该包只在编译和测试的时候用，所以，当启动tomcat的时候，就不会冲突了，完整依赖如下：

<dependency>
    <groupId>javax.servletgroupId>
    <artifactId>servlet-apiartifactId>
    <version>3.0-alpha-1version>
    <scope>providedscope>
dependency>

因为scope=provided的情况，只影响到编译，测试阶段，而在运行阶段，目标容器（比如我们这里的tomcat容器）已经提供了这个jar包，所以无需我们这个artifact对应的jar包了。

再举个scope=provided的例子。
比如说，假定我们自己的项目ProjectABC 中有一个类叫C1，而这个C1中会import包portal-impl.jar的类B1，那么在编译阶段，我们肯定需要这个B1，否则C1通不过编译。因为我们的scope设置为provided了，所以编译阶段起作用，所以C1正确的通过了编译。

那么最后我们要把ProjectABC部署到Liferay服务器上了，这时候，我们到$liferay-tomcat-home\webapps\ROOT\WEB-INF\lib下发现，里面已经有了一个portal-impl.jar了，换句话说，容器已经提供了这个jar，所以，我们在运行阶段，这个C1类直接可以用容器提供的portal-impl.jar中的B1类，而不会出任何问题。

注：实际maven install生成最终的构件包ProjectABC.war后，在其下的WEB-INF/lib中，会包含被标注为scope=compile的构件的jar包，而不会包含被标注为scope=provided的构件的jar包。这也避免了此类构件当部署到目标容器后产生包依赖冲突。

runtime

含义：表示被依赖项目无需参与项目的编译，但是会参与到项目的测试和运行。与compile相比，被依赖项目无需参与项目的编译。

适用场景：例如，在编译的时候我们不需要 JDBC API 的 jar 包，而在运行的时候我们才需要 JDBC 驱动包。

test

含义： 表示被依赖项目仅仅参与测试相关的工作，包括测试代码的编译，执行。

适用场景：例如，Junit 测试。

system

含义：system 元素与 provided 元素类似，但是被依赖项不会从 maven 仓库中查找，而是从本地系统中获取，systemPath 元素用于制定本地系统中 jar 文件的路径。例如：

<dependency>
    <groupId>org.opengroupId>
    <artifactId>open-coreartifactId>
    <version>1.5version>
    <scope>systemscope>
    <systemPath>${basedir}/WebContent/WEB-INF/lib/open-core.jarsystemPath>
dependency>

一般用于Maven项目引入第三方Jar文件。比如使用第三方Jar文件，而指定的远程仓库没有该Jar文件，可以先把需要的Jar导入到项目，然后pom文件通过 system 和 … 指定本地Jar文件。详细步骤见 《Intellij IDEA在maven项目中添加外部Jar包运行》

import

它只使用在<dependencyManagement>中，表示从其它的pom文件中导入dependency的配置。

例子：SpringBoot应用需要继承父类 spring-boot-starter-parent，需要添加 。

<parent>
    <groupId>org.springframework.bootgroupId>
    <artifactId>spring-boot-starter-parentartifactId>
    <version>2.1.6.RELEASEversion>
parent>

继承父模块spring-boot-starter-parent，然后再引入相应的依赖。

假如说，我不想继承，或者我想继承多个，怎么做？

我们知道Maven的继承和Java的继承一样，是无法实现多重继承的。如果10个、20个甚至更多模块继承自同一个模块，那么按照我们之前的做法，这个父模块的dependencyManagement会包含大量的依赖。如果你想把这些依赖分类以更清晰的管理，那就不可能了。

import scope依赖能解决这个问题。

你可以把dependencyManagement放到单独的专门用来管理依赖的pom中，然后在需要使用依赖的模块中通过import scope依赖，就可以引入dependencyManagement。

例如可以写这样一个用于依赖管理的pom：tools-1.0.0.pom

<project>
    <modelVersion>4.0.0modelVersion>
    <groupId>com.ymqxgroupId>
    <artifactId>toolsartifactId>
    <packaging>pompackaging>
    <version>1.0.0version>
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>junitgroupId>
                <artifactId>junitartifactId>
                <version>4.8.2version>
            dependency>
            <dependency>
                <groupId>log4jgroupId>
                <artifactId>log4jartifactId>
                <version>1.2.16version>
            dependency>
        dependencies>
    dependencyManagement>
project>

然后我就可以通过非继承的方式来引入这段依赖管理配置：

<project>
    ...
	
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>com.ymqxgroupId>
                <artifactId>toolsartifactId>
                <version>1.0.0version>
                <type>pomtype>
                <scope>importscope>
            dependency>
        dependencies>
    dependencyManagement>
    
	<dependencies>
        <dependency>
            <groupId>junitgroupId>
            <artifactId>junitartifactId>
        dependency>
        <dependency>
            <groupId>log4jgroupId>
            <artifactId>log4jartifactId>
        dependency>
	dependencies>
project>

dependencyManagement中的dependency 指定 groupId：com.ymqx、artifactid：tools、version：1.0.0、type：pom 以及 scope：import 。

dependencies中的dependency就可以引用依赖管理tools-1.0.0.pom 的具体依赖。

这样，父模块的pom就会非常干净，由专门的packaging为pom来管理依赖，也契合的面向对象设计中的单一职责原则。此外，我们还能够创建多个这样的依赖管理pom，以更细化的方式管理依赖。这种做法与面向对象设计中使用组合而非继承也有点相似的味道。

注意：import scope只能用在里面

那么，如何用这个方法来解决SpringBoot的那个继承问题呢？
配置如下：

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.bootgroupId>
            <artifactId>spring-boot-dependenciesartifactId>
            <version>2.1.6.RELEASEversion>
            <type>pomtype>
            <scope>importscope>
        dependency>
    dependencies>
dependencyManagement>
 
<dependencies>
    <dependency>
        <groupId>org.springframework.bootgroupId>
        <artifactId>spring-boot-starter-webartifactId>
    dependency>
dependencies>

这样配置的话，自己的项目里面就不需要继承SpringBoot的module了，而可以继承自己项目的module了。

scope的依赖传递

实际开发的项目中，各种依赖相互之间的关系很混乱。不同的依赖范围会导致不同的结果，看一下下面简单的例子：

A–>B–>C。当前项目为A，A依赖于B，依赖范围是test；B依赖于C，依赖范围是compile。那么C在A的classpath下是test作用域。

具体规则如下：

第一列表示A对B的scope，第一行表示B对C的scope。A对C的scope就是内部具体对应的位置所示。横线表示依赖无法传递。

规则可以总结如下：

• 当B对C的scope为 test、provided时，C直接被丢弃，A不依赖C。
• 当B对C的scope为 compile时，A对C的scope取决于A对B的scope。
• 当B对C的scope为 runtime时，A对C的scope取决于A对B的scope，除了compile。

参考文章：
Maven—scope和依赖传递的介绍
Maven依赖中的Scope详解