Maven中scope标签详解

作者: virtual灬zzZ | 来源:发表于2023-09-12 23:55 被阅读0次

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。

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

Maven中scope标签详解

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

compile（默认）

provided

runtime

test

system

import

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

scope的依赖传递

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

maven