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