【转】Maven实战(七)---传递依赖

时间:2021-09-30 15:59:51

原博文出自于:http://blog.csdn.net/liutengteng130/article/details/47000069   感谢!

假设A-->C  B-->A      ==> B-->C ,A依赖于C是直接依赖,B依赖于A是直接依赖,B依赖于C是传递依赖。

现象一

举个例子:A-->log1.0  B-->log2.0 C-->A,B 那么我们来看依赖关系:

User-core依赖于log4j 1.2.17

【转】Maven实战(七)---传递依赖

<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
</dependency>

User-log包依赖于log4j 1.2.9

【转】Maven实战(七)---传递依赖

<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.9</version>
</dependency>

User-service依赖于user-core,也依赖于user-log

【转】Maven实战(七)---传递依赖

可以看出user-service依赖的log4j的版本号为1.2.9。因为先依赖的log,后依赖于core,user-service依赖log4j相当于间接依赖。因此当有间接依赖的时候先依赖的哪个,就会依赖哪个包的间接依赖。

总结:间接依赖,如果级别相同,依赖于先引用的依赖。

现象二

先依赖于user-core,再依赖于user-log.下面看commons-logging.jar的版本号:

【转】Maven实战(七)---传递依赖

User-core里面的Commons-logging的版本号为1.0.4

User-log里面的Commons-logging的版本号为1.1.1

User-service里面Commons-logging的版本号为1.1.1

按照第一种,user-service里面的jar版本应该为1.0.4,现在为什么是1.1.1呢?

我们来解析:

【转】Maven实战(七)---传递依赖

User-core里面依赖于dbunit,而commons-logging.jar是作为依赖项被引用下来的

User-log里面是直接引用commons-logging.jar

因此它们处于不同的依赖树上,深度越浅越被优先选择。

小结

1.在工程的依赖树上,深度越浅,越被有限选择。

2.若两个依赖包处于依赖树上的同一层,则谁在前选择谁。

总之,避免传递依赖时引起版本问题出现的最佳实践。一般情况下,如果工程直接依赖到某一框架的多个模块,最好全部声明这些依赖。