依赖冲突是指：在 Maven 项目中，当多个依赖包，引入了同一份类库的不同版本时，可能会导致编译错误或运行时异常。
我们在 Maven 项目的 Pom 中 一般会引用许许多多的 Dependency。例如，项目A有这样的依赖关系：
A -> C -> X(1.0)B -> D -> X(2.0)X是A的 传递性依赖 ，但是两条依赖路径上有两个版本的X,那么哪个X会被 Maven 解析使用呢? 两个版本都被解析显然是不对的，因为那会造成依赖重复，因此必须选择一个。
在绝对大多数情况下，依赖冲突问题并不需要我们考虑，Maven 工具会自动根绝依赖原则选择，这里我们先假设最终引用的 X(1.0) 版本，
1、你想如果B引用 X(2.0) 的新创建的类，但因为最终被解析的是 X(1.0)，所以就会出现很典型的 NoClassDefFoundError 或 ClassNotFoundException 依赖冲突报错。
2、如果B引用 X(2.0) 的新创建的方法，但因为最终被解析的是 X(1.0)，所以就会抛出 NoSuchMethodError 系统异常。
但换种角度，如果最终解析的是 X(2.0)，就没问题了吗？
1、如果 X(2.0) 删掉了 X(1.0) 的一些类，但A已经引用了，同样也会报 NoClassDefFoundError 或者 ClassNotFoundException 错误。
2、如果 X(2.0) 删掉了 X(1.0) 的一些方法，但A已经引用了，同样也会报 NoSuchMethodError 错误。
所以说具体问题还需具体分析，到底采用哪个版本还需要看实际项目。也可能我们需要升级对应的A或者B的版本才能解决问题。
在同一个 Pom 内，相同 Jar 不同版本，根据依赖的路径长短来决定引入哪个依赖。
举例
依赖链路一：A -> B -> C -> X(1.0)依赖链路二：F -> D -> X(2.0)该例中 X(1.0) 的路径长度为3,而 X(2.0) 的路径长度为2,因此 X(2.0) 会被解析使用。依赖调解第一原则不能解决所有问题，比如这样的依赖关系：
A -> B -> Y(1.0)c -> D -> Y(2.0)Y(1.0) 和 Y(2.0) 的依赖路径长度是一样的，都为2。Maven 定义了依赖调解的第二原则：
在依赖路径长度相等的前提下，在同一个 Pom 中，间接依赖声明的顺序决定了谁会被解析使用，顺序最前的那个依赖优胜。该例中，如果A的依赖声明在C之前，那么 Y (1.0) 就会被解析使用.
比如 我在 demo01 中引入了 demo02 和 demo03，demo02 和 demo03 都引入了 Lombok 的依赖
图片
demo02 和 demo03 换个顺序
图片
图片
图片
我们先来解释下什么是传递性依赖
比如当我们项目中，引用了A的依赖,A的依赖通常又会引入B的 Jar 包，B可能还会引入C的 Jar 包。
这样，当你在 pom.xml 文件中添加了A的依赖，Maven 会自动的帮你把所有相关的依赖都添加进来。
就这样一层层的，Maven 会自动的帮你把所有相关的依赖都添加进来。传递性依赖会给项目引入很多依赖，简化项目依赖管理，但是也会带来问题。
最明显的就是容易发生依赖冲突。
这种情况下，想要解决依赖冲突，可以靠升级/降级某些依赖项的版本，从而让不同依赖引入的同一类库，保持一致的版本号。另外，还可以通过隐藏依赖、或者排除特定的依赖项来解决问题。
Exclusions是主动断开依赖的资源，被排除的资源无需指定版本—指不需要
也就是说可以包含一个或者多 Exclusion 子元素，因此可以排除一个或者多个传递性依赖。需要注意的是，声明 Exclusion 的时候只需要 Groupld 和 Artifactld ,而不需要要 Version 元素。
用法示例：
<dependency> <groupId>org.springframework</groupId> <artifactId>spring-web</artifactId> <version>5.1.8.RELEASE</version> <exclusions> <!-- 排除web包依赖的beans包 --> <exclusion> <groupId>org.springframework</groupId> <artifactId>spring-beans</artifactId> </exclusion> </exclusions></dependency>该标签即是“隐藏依赖”的开关,指对外隐藏当前所依赖的资源---指不透明：
用法示例：<dependency> <groupId>org.springframework</groupId> <artifactId>spring-aop</artifactId> <version>5.1.8.RELEASE</version> <optional>true</optional></dependency>
图片
图片
图片
聚合工程，即是指：一个项目允许创建多个子模块，多个子模块组成一个整体，可以统一进行项目的构建。要弄明白聚合工程，得先清楚“父子工程”的概念：
而Maven聚合工程，就是基于父子工程结构，来将一个完整项目，划分出不同的层次，这种方式可以很好的管理多模块之间的依赖关系，以及构建顺序，大大提高了开发效率、维护性。
为了防止不同子工程引入不同版本的依赖，在父工程中，统一对依赖的版本进行控制，规定所有子工程都使用同一版本的依赖，可以使用<dependencyManagement>标签来管理。
子工程在使用<dependencyManagement>中已有的依赖项时，不需要写<version>版本号，版本号在父工程中统一管理，这样做的好处在于：以后为项目的技术栈升级版本时，不需要单独修改每个子工程的POM，只需要修改父POM文件即可，减少了版本冲突的可能性。
如果你的项目中依赖许许多多的 Jar ，肉眼排查就没那么方便了，这里推荐一个 Maven 管理插件
图片
在 Pom 文件中看到 Dependency Analyzer标志，说明 Maven Helper 插件就安装成功了。
图片
点击 Dependency Analyzer 之后就会进入到下面的页面
图片
从图中可以看出有哪些jar存在冲突，存在冲突的情况下最终采用了哪个依赖的版本。标红的就是冲突版本，白色的是当前的解析版本。
如果我们想保留标红的版本，那我们可以标白区域右击选择排除(Exclude)即可。
一般我们在解决依赖冲突的时候，都会选择保留jar高的版本，因为大部分jar在升级的时候都会做到向下兼容，所以只要保留高的版本就不会有什么问题。
但是有些包，版本变化大没法去做向下兼容，高版本删了低版本的某些类或者某些方法，那么这个时候就不能一股脑的去选择高版本，但也不能选择低版本。
就比如下面这个案例
依赖链路一：A -> B -> C -> X(1.0)依赖链路二：F -> D -> X(2.0)X(2.0) 没有对 X(1.0) 做向下兼容也就是说可能存在排除哪个都不行，那怎么办我们只能考虑升级A的版本或者降低F的版本。比如A升级到A(2.0),使它依赖的X版本变成X(2.0)这样的话就解决依赖冲突。
但话有说回来 A升级到A(2.0) 可能会影响许许多多的地方，比如自己项目中代码是否需要改变，或者因为 A升级到A(2.0) 导致 B和C的版本有所改变，这些影响点都需要我们去考虑的。所以说为什么说一个大型项目稳定后，Pom文件的升级是件繁琐的事情，那是因为考虑的东西是在太多了，稍有不慎就会因为依赖冲突而导致系统报错。
本文链接：http://www.28at.com/showinfo-26-75318-0.html我们一起聊聊 Maven 依赖冲突问题
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： 想徒手写个文件系统？来一起呀
下一篇： 前端视角对Rust的浅析
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
