maven 重复依赖不同版本 选择规则
本篇主要来看看 maven 对于 重复依赖的jar的不同版本时候 它内部的选择规则, 很多时候我们在搭建环境的时候 不注意就会存在依赖冲突等问题 那依赖冲突的时候 为什么maven选择了不是你如你所想的jar 版本呢 , 其实都是有一定规则的 下面来看看吧
1.前言
我们在使用maven 的时候 多多少少遇到过jar包冲突的问题, 在对一个jar包引入不同版本后,可能会导致NoSuchMethodError 错误, 那么你真的清楚 maven 在多个版本jar的时候是怎么去选择版本的呢? 如果理解这些 在加上一些依赖冲突辅助工具,可以让你更加快速的解决这类问题
2.重复依赖选择原则
先把重复依赖后 选择原则抛出来 待会一个个进行验证
- 最短路径原则: 两级以上的不同级依赖, 选择路径最短
- 声明优先原则 : 两级以上的同级依赖,先声明的覆盖后声明的
- 同级依赖后加载覆盖先加载原则
3.前置准备
-
创建 web , service , common 模块
-
使用 elasticsearch-rest-high-level-client 和 elasticsearch-rest-client 配合 演示
4.最短路径原则
最短路径原则的前提是 两级以上的不同级依赖, 选择路径最短
4.1 common 模块
common 模块中引入了 elasticsearch-rest-high-level-client 7.4.2 而它依赖了 elasticsearch-rest-client 7.4.2
common pom
:
<dependencies>
<dependency>
<groupId>org.elasticsearch.clientgroupId>
<artifactId>elasticsearch-rest-high-level-clientartifactId>
<version>7.4.2version>
dependency>
dependencies>
4.2 service 模块
service 模块中 直接引入了 elasticsearch-rest-client 6.8.13
service pom
:
<dependencies>
<dependency>
<groupId>org.elasticsearch.clientgroupId>
<artifactId>elasticsearch-rest-clientartifactId>
<version>6.8.13version>
dependency>
dependencies>
4.3 idea maven 分析工具
打开idea 的maven 部分可以看到 已经提示我们 有依赖冲突了, 其实它标注在 common模块中的下 就表示这个冲突了 不使用它
4.4 mvn dependency:tree
可以通过 mvn dependency:tree 去查看 项目的依赖树 , 可以看到 最短路径原则 生效了, maven 选择了短路径的 service模块的 elasticsearch-rest-client:6.8.13 版本
5.声明优先原则
声明优先原则: 前提是 两级以上的同级依赖, 先声明的覆盖后声明的
把上面的依赖结构改一下
5.1 common 模块
让common 模块直接依赖 elasticsearch-rest-client 7.4.2
<dependencies>
<dependency>
<groupId>org.elasticsearch.clientgroupId>
<artifactId>elasticsearch-rest-clientartifactId>
<version>7.4.2version>
dependency>
dependencies>
5.2 service 模块
<dependencies>
<dependency>
<groupId>org.elasticsearch.clientgroupId>
<artifactId>elasticsearch-rest-clientartifactId>
<version>6.8.13version>
dependency>
dependencies>
5.3 验证 web 模块 (common 在 service 前)
<dependencies>
<dependency>
<groupId>org.examplegroupId>
<artifactId>backend_commonartifactId>
<version>1.0-SNAPSHOTversion>
dependency>
<dependency>
<groupId>org.examplegroupId>
<artifactId>backend_serviceartifactId>
<version>1.0-SNAPSHOTversion>
dependency>
dependencies>
记得需要重新打包模块 mvn clean install
由于 依赖顺序 common 在 service 之前 选择了 common 中的依赖
5.4 验证 web 模块 (service 在 common 前)
<dependencies>
<dependency>
<groupId>org.examplegroupId>
<artifactId>backend_serviceartifactId>
<version>1.0-SNAPSHOTversion>
dependency>
<dependency>
<groupId>org.examplegroupId>
<artifactId>backend_commonartifactId>
<version>1.0-SNAPSHOTversion>
dependency>
dependencies>
记得需要重新打包模块 mvn clean install
由于 依赖顺序 service 在 common 之前 选择了 service 中的依赖
至此声明优先原则 验证完毕
6.同级依赖后加载 覆盖 先加载原则
将依赖改成如下
6.1 web 模块
在web 的pom 中 直接引入2个 版本的依赖
6.2 验证 web模块(client 7.4.2 在 client 6.8.13 前)
<dependencies>
<dependency>
<groupId>org.elasticsearch.clientgroupId>
<artifactId>elasticsearch-rest-clientartifactId>
<version>7.4.2version>
dependency>
<dependency>
<groupId>org.elasticsearch.clientgroupId>
<artifactId>elasticsearch-rest-clientartifactId>
<version>6.8.13version>
dependency>
dependencies>
记得需要重新打包模块 mvn clean install
6.3 验证 web模块(client 6.8.13 在 client 7.4.2 前)
<dependencies>
<dependency>
<groupId>org.elasticsearch.clientgroupId>
<artifactId>elasticsearch-rest-clientartifactId>
<version>6.8.13version>
dependency>
<dependency>
<groupId>org.elasticsearch.clientgroupId>
<artifactId>elasticsearch-rest-clientartifactId>
<version>7.4.2version>
dependency>
dependencies>
记得需要重新打包模块 mvn clean install
7. idea 插件 maven helper
最后 推荐一款 idea 中 可以分析快速解决 maven 依赖冲突的 插件 maven helper
下面依赖标注的 6.8.13 也表示了 当前maven 选择的 jar 版本
总结
本篇非常详细了介绍了 maven 中当有重复依赖不同版本jar 的时候 maven 选择jar的 几个规则,并且都一一做了 验证, 你学会了吗, maven 平时我们都是只是 复制粘贴用一用 但是当你遇到问题的时候 需要快速解决它的能力,加油吧!
欢迎大家访问 个人博客 Johnny小屋
欢迎关注个人公众号