Maven实战（七）---传递依赖

         如果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

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

 

         User-log包依赖于log4j 1.2.9

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

 

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

      

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

总结：间接依赖，假设级别同样，依赖于先引用的依赖。

 

 

现象二

         

       先依赖于user-core,再依赖于user-log.以下看commons-logging.jar的版本：

                          

           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呢？

         我们来解析：

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

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

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

 

小结

         1.在project的依赖树上。深度越浅，越被有限选择。

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

      

          总之。避免传递依赖时引起版本号问题出现的最佳实践。普通情况下。假设project直接依赖到某一框架的多个模块。最好所有声明这些依赖。