maven的依赖传递

 

 

scope范围

名称	有效范围
Compile	编译，测试，运行。默认的依赖范围
Test	测试，如Junit
Runtime	运行，如JDBC
Provided	编译，测试，如ServletAPI
System	编译，测试，依赖于系统变量

compile

maven默认的范围就是compile，在所有的classpath中可用，同时它们也会被打包。

provided依赖只有在当JDK或者一个容器已经提供该依赖之后才使用。例如：开发了一个web应用，你可能在编辑classpath中需要使用servlet API来编辑一个servlet，但是你不会想要在打包更好的WAR中包含这个servlet API，因为该API由同期或者JDK直接提供。该范围的依赖不存在传递性，也不会被打包。

runtime在运行和测试系统时需要，但是在编辑时不需要，比如：可能在编辑的时候只需要JDBC API JAR ,只有在运行的时候才需要JDBC驱动的实现。

test编辑和测试的时候使用。

 

 

system范围依赖与provided类似，但是你必须显式的提供一个对于本地系统中JAR文件的路径。这么做是为了允许基于本地对象编译，而这些对象是系统类库的一部分。这样的构建应该是一直可用的，Maven 也不会在仓库中去寻找它。如果你将一个依赖范围设置成系统范围，你必须同时提供一个systemPath元素。注意该范围是不推荐使用的（建议尽量去从公共或定制的 Maven 仓库中引用依赖）。示例如下：

<project>
  <dependencies>
    <dependency>
      <groupId>sun.jdk</groupId>
      <artifactId>tools</artifactId>
      <version>1.5.0</version>
      <scope>system</scope>
      <systemPath>${java.home}/../lib/tools.jar</systemPath>
    </dependency>
    ...
  </dependencies>
</project>

 

依赖传递

说明：

第一列是A对B的依赖，第一行是B对C的依赖

• 当B对C的依赖的scope是test或者provided，则A不依赖C。
• 当B对C的依赖是scope是runtime或者compile，则A依赖C。且传递依赖的scope的规则：如果A对B的依赖是compile，那么A对C的依赖和B对C的依赖相同，否则和A对B的依赖保持一致

 

依赖传递：A依赖B，B依赖C，那么A依赖C

     上面描述没有问题的。但是有时候C中设定的依赖版本，但是在A中并查看依赖的版本，并非是C中设定的依赖版本，一直以来都感觉这是maven的bug，但实际上是我之前错了，在传递依赖的时候版本也有一定的规则。

  依赖传递的规则，以mysql的5.1.45以及8.0.11为例：

     1、在本模块B的pom声明了版本，则mysql版本即为此处指定的版本。

     2、为同一个pom中声明了两次mysql这两个版本，谁在下面谁生效

     3、父模块A中声明了mysql版本，使用dependencyManagement设定了版本，并且在引用的地方B模块并未指明版本，则以B中引用过来的B的版本就是A中设定的版本并非是C本身自己的版本。

     4、依赖距离的问题

         （1）长度相同

          上面：B依赖C

          又有一个依赖：B依赖D

          C和D中都有对mysql不同版本的引用。

           C和D到B的长度相同，那么这个时候B的pom中谁的依赖在前面谁生效。

           

         （2）长度不相同

          上面：B依赖C

          又有一个依赖：B依赖E，E依赖 D

          C和D中都有对mysql不同版本的引用。

          C和D到B的长度不相同，那么这个时候谁离B短谁生效，此处很明显就是C生效。