scope元素的作用：控制 dependency 元素的使用范围，即控制 Jar 包在哪些范围被加载和使用。具体值如下：
compile：默认值。表示被依赖项目需要参与当前项目的编译、测试、打包、运行，是一个比较强的依赖。
test：依赖项目仅仅参与测试相关的工作。包括测试代码的编译和执行，不会被打包，例如：junit。
runtime：表示被依赖项目无需参与项目的编译，不过参与后期的测试、打包、运行。与compile相比，跳过了编译。例如JDBC驱动，适用运行和测试阶段。
provided：理论上可以参与编译，测试等周期，但不被打包，也不会参与运行，因为其他的依赖会提供。相比于compile，打包阶段做了exclude操作。
system：和provided相同。不过被依赖项不会从maven仓库下载，而是从本地文件系统拿。需要添加systemPath的属性来定义路径。一般用于引用外部Jar包。
import：它只使用在<dependencyManagement>中，表示从其它的pom文件导入dependency的配置。
compile（默认）
含义：compile 是默认值，如果没有指定 scope 值，该元素的默认值为 compile。被依赖项目需要参与到当前项目的编译，测试，打包，运行等阶段。打包的时候通常会包含被依赖项目。
provided
含义：被依赖项目理论上可以参与编译、测试、运行等阶段，相当于compile，但是再打包阶段做了exclude的动作。
例：开发web的时候，需要用到servlet-api，于是在pom.xml中添加依赖：
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>3.0-alpha-1</version>
</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.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>3.0-alpha-1</version>
<scope>provided</scope>
</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.open</groupId>
<artifactId>open-core</artifactId>
<version>1.5</version>
<scope>system</scope>
<systemPath>${basedir}/WebContent/WEB-INF/lib/open-core.jar</systemPath>
</dependency>
一般用于Maven项目引入第三方Jar文件。比如使用第三方Jar文件，而指定的远程仓库没有该Jar文件，可以先把需要的Jar导入到项目，然后pom文件通过 <scope>system</scope> 和 <systemPath>…</systemPath> 指定本地Jar文件。详细步骤见 《Intellij IDEA在maven项目中添加外部Jar包运行》
import
它只使用在<dependencyManagement>中，表示从其它的pom文件中导入dependency的配置。
例子：SpringBoot应用需要继承父类 spring-boot-starter-parent，需要添加 <parent>。
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.1.6.RELEASE</version>
</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.0</modelVersion>
<groupId>com.ymqx</groupId>
<artifactId>tools</artifactId>
<packaging>pom</packaging>
<version>1.0.0</version>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8.2</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.16</version>
</dependency>
</dependencies>
</dependencyManagement>
</project>
然后我就可以通过非继承的方式来引入这段依赖管理配置：
<project>
...
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.ymqx</groupId>
<artifactId>tools</artifactId>
<version>1.0.0</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</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只能用在<dependencyManagement>里面
那么，如何用这个方法来解决SpringBoot的那个继承问题呢？
配置如下：
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>2.1.6.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</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。
