Maven版本冲突解决方式

使用maven进行项目构建非常方便，极大的解放了开发的精力，但是，随着项目的依赖越来越复杂，版本维护也随之复杂起来，此时版本冲突及排查将是家常便饭。

说下maven的依赖版本选择机制，比如某个项目A需要依赖B，且实际依赖路径为A->B(old)，然后A的其中一个依赖C，同样依赖了B，且版本较新，该依赖路径为A->C->B(new)，项目A最终的有效依赖B将是B(old)，那么C的功能中接口也是B(old)，此时运行过程就会有问题，因为old版本无法满足C的正常使用。

以上的版本选择机制就是maven的就近原则。

接下来奉上一般的解决思路

1. 以上示例的情况，此时应该将A的依赖B进行更新操作，这样保证各方都能维持统一【这个属于协商阶段，适合于能够明确找到冲突路径的情况】
2. 还有一种，也是比较难啃的，就是正常预期是A->C(1.1)->B(1.1)，但是B的版本实际1.0，查找依赖树，找不到是哪里将B的版本改成了1.0，这个比较暴力的做法就是直接在A中引入B，并且直接指定版本为1.1即可（maven的就近原则）

附：

gradle打包的项目如何在maven中进行依赖关系维护的？

maven的包部署到仓库后，会有jar和pom两个文件，jar是实际的二进制文件，pom则是maven进行维护依赖关系的核心文件。之前一直有个疑惑，就是IDE中查看jar包里边没有pom文件，但是却有依赖树。【其实就是jar包里的pom没有任何鸟用，误区是之前一直以为是通过jar包里的pom进行依赖查询的】