影响maven传递性依赖的几个因素

影响maven传递性依赖主要有以下几个因素，本文也从这几个因素展开做介绍

影响依赖能否传递下去的因素

• 依赖作用范围<scope>

• 可选依赖<optional>

• 排除依赖<exclusion>

影响依赖传递版本的因素

• 最短路径优先原则
• 最先申明原则
• 子pom内的依赖会覆盖父pom

1. 依赖作用范围

依赖可作用的范围有编译、运行、测试。

<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。