影响maven传递性依赖主要有以下几个因素,本文也从这几个因素展开做介绍
影响依赖能否传递下去的因素
- 依赖作用范围<scope>
- 可选依赖<optional>
- 排除依赖<exclusion>
影响依赖传递版本的因素
- 最短路径优先原则
- 最先申明原则
- 子pom内的依赖会覆盖父pom
依赖作用范围
依赖可作用的范围有编译、运行、测试。
<scope>有6种配置,分别是compile、runtime、test、provider、system、import(Maven2.0.9及以上)。
| compile | runtime | test | provider | system | import |
作用范围 | 编译、运行、测试 | 编译时不依赖,对运行、测试下的classpath依赖 | 编译测试、运行测试下的classpath依赖,程序正常运行不依赖 | 对编译、测试下的classpath | | |
是否会传递 | 是 | 是 | 否 | 否 | 否 | 否 |
使用场景 | 如典型的spring相关依赖包 | 如JDBC驱动 | 如junit、testng、spring-test | 如sevlet-api,在运行时web容器已提供,不需要maven重复引入 | 与systemPath结合使用指定本地jar路径,一般不使用 | 只适用于pom文件中的<dependencyManagement>部分。表明指定的POM必须使用<dependencyManagement>部分的依赖。一般不使用 |
可选依赖
如A->B,A只用到了B的部分功能,则可将B设置为<optional>true</optional>,此时,若项目X->A,则X不会进行依赖传递到B,即X不会依赖B。如果需要,可显示的添加X对B的依赖。
<dependency>
<groupId>group.B</groupId>
<artifactId>B</artifactId>
<version>1.0</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>
排除依赖
如果项目X依赖于项目Y,项目Y又依赖项目Z,项目X的所有者可以使用”exclusion”元素来显式排除项目Z。如
<dependency>
<groupId>commons-beanutils</groupId>
<artifactId>commons-beanutils</artifactId>
<version>${commons.beanutils.version}</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
最短路径优先原则
项目依赖关系树中路径最短的版本会被使用。
如A、B、C之间的依赖关系是A->B->C->D(2.0)和A->E->D(1.0),其实A依赖的是D(1.0),因为A通过E到D的路径更短。若想要强制使用D(2.0),那你也可以在A中显式声明对D(2.0)的依赖。
最先申明原则
在依赖关系树中,最先申明的会被引用,如A->B->D(2.0),A->E->D(1.0),此时A对D的依赖路径一样长,如果B优先于E申明,则A依赖的是D(2.0)。
子pom内的依赖会覆盖父pom中的依赖,包括版本号、scope
如在子pom内申明依赖A-1.0,scope为test,父pom中A-2.0,scope为runtime,实质上子model引用的是A-1.0,scope-test。