maven传递依赖的版本确定规则,也就是对重复的间接依赖的包的选择规则:
1. 在工程的依赖树上,深度越浅,越被优先选择。如本例中的spring-jms. 由于pom中直接声明了3.0.2版本的spring-jms,所以3.0.2版本的spring-jms在工程的依赖树上处在第一层,而activemq-optional所间接依赖的3.0.3版本的spring-jms则是处在工程依赖树的第二层,则maven会以深度浅者优先,所以最后解析的结果是选择了3.0.2版本的spring-jms。
2. 若两个依赖包处于依赖树上的同一层,则谁在前,选择谁。如本例中的spring-core.一个是activemq-optional的间接依赖,一个是spring-context的间接依赖,两个依赖都是处在第二层上,但由于是activemq-optional声明在前,所以maven优先选择了activemq-optional所依赖的3.0.3的版本!
3. 避免传递依赖引起版本问题的最佳实践。现在很多的开源框架和工具都开始分模块打包发布,比如spring,hibernate都是如此,而这些模块之间又有可能存在相关的依赖关系,为了避免出现版本不一致问题,比如上例中出现的spring-jms使用的是3.0.2,而spring-core却使用了3.0.3这种情况,需要我们对一个工程直接依赖的某一框架的多个模块都要做出声明,而不要依赖其内部的依赖关系来间接引入。总结起来就昌:一般来说,如果工程直接依赖到某一框架的多个模块,最好全部声明这些依赖。
再分享一下我老师大神的人工智能教程吧。零基础!通俗易懂!风趣幽默!还带黄段子!希望你也加入到我们人工智能的队伍中来!https://blog.csdn.net/jiangjunshow