Maven - 依赖冲突

依赖传递

参见：Maven依赖机制简介

总结：
一句话概括：当项目A依赖于B，而B又依赖于C的时候，自然的A会依赖于C，这样Maven在建立项目A的时候，会自动加载对C的依赖

image.png

依赖冲突

总结：
既然依赖可以传递，那么工程就能获取到依赖的所有版本。当传递的依赖有多个版本时，就产生了冲突

image.png image.png

依赖选取

总结：
冲突是客观存在的，需要有策略能解决冲突。

Maven依赖选取原则

• 最短路径
• 最先声明

最短路径

image.png

依赖e的版本为1.2版本

最先声明

image.png

如果在工程A中，先声明对依赖b的依赖，由于依赖b依赖d的1.1版本，因此工程A会依赖d的1.1版本

冲突分析

不解决冲突，可能会出现ClassNotFoundException或NoSuchMethodException。如下所示：

image.png

分析方法
参见Maven提高篇系列之（五）——处理依赖冲突
Maven类包冲突终极解决小技若干

总结为：

• 使用dependency:tree分析依赖

• 使用mvn dependency:tree -Dverbose查看更多信息，尤其conflict

• 不想被其他信息干扰，添加Dincludes或者Dexcludes来排除干扰，如下只显示asm:asm相关的信息：

mvn dependency:tree -Dverbose -Dincludes=asm:asm

• mvn dependency:analyze?

image.png image.png

如上图所示，curator-framework依赖curator-client的版本是2.12.0。但是根据依赖选取规则，选取的curator-client版本是2.7.1。这样curator-framework只能降级，使用2.7.1版本的curator-client。如果使用了只有在2.12.0中存在的方法，那么就会报错。

绝大多数情况下，高版本都会兼容低版本。因此，使maven选取高版本的依赖，是比较好的做法。

解决冲突

参见：Maven 依赖管理

总结

• 缩短指定版本的路径
• exclude掉不想要的版本
• 将依赖声明为optional

image.png

根据依赖选取策略，snappy-java的1.1.4版本会被选取。这个明显高于其他的1.1.1.6和1.1.2.6版本。一般情况下，高版本会兼容低版本，因此这种情况通常不会出问题。

参考

• Maven提高篇系列之（五）——处理依赖冲突
• Maven类包冲突终极解决小技若干