如何在IDEA中快速解决Jar冲突详解
⽬录
⼀、为什么会产⽣Jar包冲突?
1.1 直接与传递依赖
1.2 Maven 的传递依赖
1.3 Maven 如何解决版本冲突？
1.4 覆盖传递依赖版本
1.5 使⽤直接依赖覆盖传递依赖版本
⼆、通过IDEA快捷解决依赖冲突
2.1 查冲突
2.2 发现冲突
2.3 解决冲突
⼀、为什么会产⽣Jar包冲突?
作为 Java 开发⼈员，我们可能会使⽤Maven维护许多应⽤程序以进⾏依赖项管理。这些应⽤程序需要不时升级以保持最新状态并添加新功能或安全更新。
由于某些依赖项之间的冲突，这个简单的任务 - 更新依赖项的版本，很容易变成⼀场噩梦。解决这些依赖冲突可能需要很多时间。
1.1 直接与传递依赖
Maven中有两种类型的依赖项：
直接依赖项：
部分中明确包含在我们的项⽬对象模型 ( l) ⽂件中的依赖项<dependencies>。可以使⽤<dependency>标签添加它们。以下是添加到l⽂件中的⽇志库⽰例：
<dependencies>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
</dependency>
</dependencies>
传递依赖项：
我们作为依赖项包含在项⽬中的项⽬，如上⾯的⽇志库，可以在l⽂件中声明⾃⼰的依赖项。然后将这些依赖项视为对我们项⽬的传递性依赖项。当Maven拉取⼀个直接依赖时，它也会拉取它的传递依赖。
1.2 Maven 的传递依赖
现在我们对Maven中的不同依赖类型有了⼀个概述，让我们详细看看Maven如何处理项⽬中的传递依赖。
作为⽰例，我们将查看 Spring 框架中的两个依赖项：spring-context和spring-security-web.
在l⽂件中我们将它们添加为直接依赖项，特意选择了两个不同的版本号：
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>5.3.5</version>
</dependency>
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-web</artifactId>
<version>5.4.5</version>
</dependency>
</dependencies>
使⽤依赖树可视化版本冲突
不了解传递依赖的⼈会认为使⽤这个依赖声明只会拉取两个JAR⽂件。幸运的是，Maven提供了⼀个命令，它将向我们展⽰与这两个依赖项相关的确切内容。
我们可以使⽤以下命令列出所有依赖项，包括可传递的依赖项：
mvn dependency:tree -Dverbose=true
我们使⽤此命令的详细模式，以便Maven告诉我们选择⼀个版本的依赖项⽽不是另⼀个版本的原因。
结果是这样：
+- org.springframework:spring-context:jar:5.3.5:compile
|  +- org.springframework:spring-aop:jar:5.3.5:compile
|  |  +- (org.springframework:spring-beans:jar:5.3.5:compile - omitted for duplicate)
|  |  \- (org.springframework:spring-core:jar:5.3.5:compile - omitted for duplicate)
|  +- org.springframework:spring-beans:jar:5.3.5:compile
|  |  \- (org.springframework:spring-core:jar:5.3.5:compile - omitted for duplicate)
...
+- (org.springframework:spring-expression:jar:5.2.13.RELEASE:compile - omitted for conflict with 5.3.5)
\- org.springframework:spring-web:jar:5.2.13.RELEASE:compile
+- (org.springframework:spring-beans:jar:5.2.13.RELEASE:compile - omitted for conflict with 5.3.5)
\- (org.springframework:spring-core:jar:5.2.13.RELEASE:compile - omitted for conflict with 5.3.5)
我们从两个依赖开始，在这个输出中，我们发现Maven拉取了额外的依赖。这些额外的依赖只是传递性的。
我们可以看到树中有相同依赖项的不同版本。例如，有两个版本的spring-beans依赖项：5.2.13.RELEASE和5.3.5.
Maven解决了此版本冲突，但是如何解决？什么是省略了重复和省略的冲突是什么意思？
1.3 Maven 如何解决版本冲突？
⾸先要知道的是，Maven ⽆法对版本进⾏排序：版本是任意字符串，可能不遵循严格的语义序列。例如，如果我们有两个版本1.2和 1.11，我们知道1.11在之后1.2但字符串⽐较给出了1.11之前1.2。其他版本值可以是1.1-rc1 或 1.1-FINAL，这就是为什么按 Maven 对版本进⾏排序不是解决⽅案的原因。
这意味着 Maven 不知道哪个版本是新的或旧的，并且不能选择总是采⽤最新的版本。
其次，Maven采⽤树深度最近的传递依赖并且根据解析顺序中排第⼀位的版本去解决。为了理解这⼀点，让我们看⼀个例⼦：
我们从⼀个 POM ⽂件开始，它有⼀些具有传递依赖关系的依赖关系（简⽽⾔之，所有的依赖关系都⽤字母 D 表⽰）：
D1(v1) -> D11(v11) -> D12(v12) -> DT(v1.3)
D2(v2) -> DT(v1.2)
D3(v3) -> D31(v31) -> DT(v1.0)
D4(v4) -> DT(v1.5)
请注意，每个直接依赖项都会引⼊不同版本的DT依赖项。
Maven将创建⼀个依赖树，并按照上⾯提到的标准，将选择⼀个依赖项DT：
我们注意到解析顺序在选择DT依赖项⽅⾯发挥了重要作⽤，因为v1.2和v1.5具有相同的深度，但v1.2在解析顺序中排在第⼀位。所以即使v1.2不是的最后⼀个版本DT，Maven也选择了它来使⽤。
如果我们想v1.5在这种情况下使⽤version，我们可以简单地在我们的POM⽂件中添加D4之前的依赖项D2。在这种情况下，v1.5将⾸先按照解析顺序，Maven 将选择它。
因此，为了帮助我们理解上⾯的依赖树结果，Maven为每个传递依赖指明了为什么它被省略：
“省略重复” 意味着Maven更喜欢另⼀个具有相同名称和版本的依赖项⽽不是这个依赖项（即另⼀个依赖项根据解析顺序和深度具有更⾼的优先级）
“因冲突⽽省略” 意味着Maven更喜欢另⼀个具有相同名称但版本不同的依赖项（即根据解析顺序和深度，具有不同版本的另⼀个依赖项具有更⾼的优先级）
现在我们很清楚Maven是如何解决传递依赖的。出于某种原因，有⼀天我们可能会选择⼀个特定版本的依赖项，并摆脱Maven为选择它所做的所有过程。为此，我们有两个选择:
spring怎么读取jar文件
1.4 覆盖传递依赖版本
如果我们想⾃⼰解决依赖冲突，我们必须告诉Maven选择哪个版本。有两种⽅法可以做到这⼀点。
1.5 使⽤直接依赖覆盖传递依赖版本
对于有⼦模块的项⽬，为了确保所有模块之间的兼容性和⼀致性，我们需要⼀种⽅法来在所有⼦模块之间提供相同版本的依赖项。为此，我们可以使⽤以下dependencyManagement部分：它为Maven提供了⼀个查表，以帮助确定传递依赖项的选定版本并集中依赖项信息。
⼀个dependencyManagement 部分包含依赖项元素。每个依赖项都是 Maven 的查参考，以确定要为传递（和直接）依赖项选择的版本。在本节中，依赖项的版本是强制性的。但是，在该dependencyManagement 部分之外，我们现在可以省略依赖项的版本，Maven 将从中提供的依赖项列表中选择正确版本的传递依赖项dependencyManagement。
需要注意的是，在dependencyManagementsection 中定义⼀个依赖并不会将其添加到项⽬的依赖树中，它仅⽤于查引⽤。
理解使⽤的更好⽅法dependencyManagement是通过⼀个例⼦。让我们回到之前的 Spring 依赖⽰例。现在我们要玩spring-beans依赖。当我们执⾏命令时mvn dependency:tree，解析的版本spring-beans是5.3.5.
使⽤dependencyManagement我们可以覆盖这个版本并选择我们想要的版本。我们所要做的就是将以下内容添加到我们的 POM ⽂件中：
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>5.2.13.RELEASE</version>
</dependency>
</dependencies>
</dependencyManagement>
现在我们希望Maven解析version 5.2.13.RELEASE⽽不是5.3.5.
让我们再执⾏mvn dependency:tree⼀次命令。结果是：
+- org.springframework:spring-context:jar:5.3.5:compile
|  +- org.springframework:spring-aop:jar:5.3.5:compile
|  +- org.springframework:spring-beans:jar:5.2.13.RELEASE:compile
|  +- org.springframework:spring-core:jar:5.3.5:compile
|  |  \- org.springframework:spring-jcl:jar:5.3.5:compile
|  \- org.springframework:spring-expression:jar:5.3.5:compile
\- org.springframework.security:spring-security-web:jar:5.4.5:compile
+- org.springframework.security:spring-security-core:jar:5.4.5:compile
\- org.springframework:spring-web:jar:5.2.13.RELEASE:compile
在依赖关系树，我们到了5.2.13.RELEASE版本spring-beans。这是我们希望Maven为每个spring-beans传递依赖解析的版本。
如果spring-beans是直接依赖，为了利⽤该dependencyManagement部分，我们将不再需要在添加依赖时设置版本：
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
</dependency>
这样，Maven将使⽤dependencyManagement部分中提供的信息解析版本。
⼆、通过IDEA快捷解决依赖冲突
2.1 查冲突
打开l，点击右键Diagrams->Show Dependencies
2.2 发现冲突
IDEA如果发现Jar冲突，会⽤红⾊线⾼亮现实。在这⾥，我们可以发现l中有两个版本的json-path包，分别是2.3.0和2.3.0
这时候我们只需要把其中⼀个包右键选择Exclude，它就会⾃动帮我们把对应的jar排除掉，这⾥我选择的是把低版本移除
冲突Jar移除后，新的依赖图已经没有了红线
到此这篇关于如何在IDEA中快速解决Jar冲突详解的⽂章就介绍到这了，更多相关IDEA解决Jar冲突内容请搜索以前的⽂章或继续浏览下⾯的相关⽂章希望⼤家以后多多⽀持！

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。