Maven依赖解析

Posted 勿忘__初心

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Maven依赖解析相关的知识,希望对你有一定的参考价值。

本文将记录Maven工程中依赖解析机制,内容包括:

  1. Maven依赖基本结构
  2. 从仓库解析依赖的机制
  3. 依赖传递性解析实例

1. Maven依赖基本结构

上篇文章记录了Maven依赖的聚合与继承,POM中依赖的声明通过dependency进行定义,并且通过groupId、artifactId及version三项定位Maven库中的唯一依赖。除了这三项外,还有其他属性进行限制,如下:

复制代码
 1 <dependencies>
 2    <dependency>
 3      <groupId>...</groupId>
 4      <artifactId>...</artifactId>
 5      <version>...</version>
 6      <type>...</type>
 7      <scope>...</scope>
 8      <optional>...</optional>
 9      <exclusions>
10         <exclusion>
11             <groupId>...</groupId>
12             <artifactId>...</artifactId>
13         </exclusion>
14      </exclusions>
15    </dependency>
16 </dependencies>
复制代码
  • groupId、artifactIdversion三项不再叙说;
  • type:依赖类型,对应于项目坐标定义的packaging,默认为jar;
  • scope:依赖范围,包括compile、test、runtime、import、provided、system;
  • optional:标记依赖为可选,即依赖没有传递性;
  • exclusions:排除传递性依赖

1.1 依赖范围

  我们知道,Maven工程约定具有固定的目录结构,以便于Maven各插件对工程处理,如编译(compile)插件,会将src/main/java中的类编译到target/classes目录下,则编译对应的classpath即为target/classes。依赖范围就是控制依赖于编译classpath(target/classes)、测试classpath(target/test-classes)和运行classpath(以Web工程为例,WEB-INF/classes)的关系。具体依赖范围的讲述可参考官网文档,在此仅进行稍微总结:

  • compile:编译依赖范围,对编译、测试、运行classpath都有效,为默认范围;
  • test:测试依赖范围,仅对测试classpath有效;
  • runtime:运行时依赖范围,对测试和运行classpath有效,对编译无效,如JDBC的依赖引入,因为JDK中值声明了JDBC接口,具体实现由各厂家决定;
  • import:导入依赖范围,对三种classpath不产生实际影响,一般是导入pom类型的依赖,聚合情况下需要声明打包类型为pom,其中可包含dependencyManagement(如上一篇文章),此时对引入该依赖的工程不产生影响;
  • provided:已提供依赖范围,对测试和编译classpath有效,对运行时无效,如servlet-api在测试或编译的时候需要,在运行的时候由容器提供,故不需要重复引入;
  • system:系统依赖范围,与provided范围一致,需要明确指定该jar包,其不在Maven仓库中,感觉不太常用。

1.2 依赖传递性

依赖传递性,举例说明,比如A引用B,B引用C,正常情况下,A也会引用C依赖,即A经过传递间接引用了C(依赖为可选时,需另行处理)。具体不同范围的依赖经过传递后,其依赖范围的变化如下边(从官网扣下来的)

依赖传递的准则

  • 路径最近这优先,即在引用传递链上,获取出离本POM最近的传递性依赖;
  • 如果路径距离相同,则以取POM中的声明顺序靠前的。

1.3 可选依赖

   可选依赖不被传递。假设项目A依赖于B,B依赖于X和Y,并且X和Y声明为可选,则X和Y对A就不具有传递性了。如果A需要依赖于X或Y,则需要直接引用。

1.4 依赖排除

   假设项目A依赖于B,B依赖于C(版本为1.0),此时A会传递性依赖于C(1.0)。如果A需要引用C(2.0版本),存在两种情况:

  (1)A直接引用C(2.0),则可以不对B依赖添加exclusions元素;

  (2)A在引用B的同时,还引用D(D引用C(2.0)),则可以在引用B的时候使用exclusions元素将C(1.0)排除,也可以将D依赖声明在B之前。

2. 从仓库解析依赖的机制

   依赖解析的基本过程:当本地仓库中没有依赖构件,则Maven从远程仓库中下载;当依赖版本为快照版本时,Maven会自动计算最新的快照,并引用。

  背后的依赖解析机制概括如下:

  (1)当依赖的范围为system,则从本机文件系统中解析构件;

  (2)根据依赖坐标计算定位依赖位置后,尝试从本地仓库寻找依赖,若找到,则解析成功;

  (3)若本地仓库没有对应构件,则遍历所有远程仓库,发现后解析下载;

  (4)如果依赖的版本为RELEASE或LATEST,则读取所有远程仓库的元数据groupId/artifactId/version/maven-metadata.xml,与本地元数据合并后,计算出RELEASE或LATEST的真实值,然后基于真实值检查本地仓库和远程仓库,如步骤(2)(3);

  (5)如果依赖的版本为SNAPSHOT,类似的,读取远程仓库的元数据,并与本地元数据合并,计算出最新版本的快照,再从本地仓库和远程仓库检索。

 下边为一个快照版本依赖的元数据maven-metadata-local.xml,包括最近更新时间戳,以及存在的不同版本:

复制代码
<?xml version="1.0" encoding="UTF-8"?>
<metadata>
  <groupId>com.test</groupId>
  <artifactId>C</artifactId>
  <versioning>
    <versions>
      <version>1.0-SNAPSHOT</version>
      <version>2.0-SNAPSHOT</version>
    </versions>
    <lastUpdated>20171113125841</lastUpdated>
  </versioning>
</metadata>
复制代码

 对应文件目录结构如下:

其中每个版本中,包含对自身描述的元数据。以2.0-SNAPSHOT为例,其目录结构如下,主要包含jar和pom两部分,maven-metadata-local.xml为依赖元数据:

具体元数据内容如下,记录了该版本依赖最近一次的更新时间。在本地库中没有该构件的时候,会检索所有远程仓库,结合元数据文件,计算最新的版本;或者在进行强制更新的时候,也会计算出最新版本

复制代码
<?xml version="1.0" encoding="UTF-8"?>
<metadata modelVersion="1.1.0">
  <groupId>com.test</groupId>
  <artifactId>C</artifactId>
  <version>2.0-SNAPSHOT</version>
  <versioning>
    <snapshot>
      <localCopy>true</localCopy>
    </snapshot>
    <lastUpdated>20171117132322</lastUpdated>
    <snapshotVersions>
      <snapshotVersion>
        <extension>jar</extension>
        <value>2.0-SNAPSHOT</value>
        <updated>20171117132322</updated>
      </snapshotVersion>
      <snapshotVersion>
        <extension>pom</extension>
        <value>2.0-SNAPSHOT</value>
        <updated>20171117132322</updated>
      </snapshotVersion>
    </snapshotVersions>
  </versioning>
</metadata>
复制代码

3. 依赖传递性解析实例

   创建3个Maven工程A、B、C(命令mvn archetype:generate)。

  (1)编辑各自的POM文件,使其依赖关系如下图所示

                    

其中B为A的直接依赖,C具有传递性,为A的传递性依赖,分析其依赖树可以直观的看出依赖关系(mvn dependency:tree),如下:

  • B依赖于C(1.0)

  •  A依赖于B(1.0),间接依赖C(1.0)

(2)将B对的C的依赖改为optional,即可选的,此时A的依赖树如下,不包括C:

(3)修改POM文件,使其依赖关系如下:

          

 看A的依赖树,如下:

 综上,正常情况下依赖是具有传递性,除非声明为optional。

总结:

  • 声明依赖时,除了常用的三项位置元素,还具有包括范围、类型、可选和排除等;
  • 依赖具有传递性,具有路径优先的约定;
  • 当引用多个工程时,会潜在的引用其他依赖,需要注意是否会引错包,或者冲突;
  • Maven依赖解析,对于本地库中没有的构件,Maven会综合远程仓库与本地仓库的元数据,计算最新版本后,再引用。

参考:

以上是关于Maven依赖解析的主要内容,如果未能解决你的问题,请参考以下文章

Maven 无法解析项目的依赖关系

Maven Java API:独立依赖解析(即不是 Maven 插件)

maven依赖解析

Apache IVY 无法解析 MAVEN 项目的依赖关系

如何在依赖解析之前运行 Maven 插件

13.3.1 使用Maven运行 MyBatis Generator(MyBatis Generator逆向代码生成工具) -《SSM深入解析与项目实战》