一、前言

早前，笔者在碰到ClassNotFoundException的异常也是一脸懵逼，但是这个类确实存在于我们的项目中，觉很离奇，就厚着脸皮去问组里的大神勋哥，勋哥开始一脸鄙视，心想这个居然都不知道，抵不过我的再三追问，勋哥抛出一句tree看一下，虽然我还是不懂，但是不好意思再问下去，感觉再问下去会被打死。事后勋哥过来问我，那个依赖冲突的问题解决了没有，解决了的话，给大家分享一下解决方案，后来因为各种原因，一直没有完成那个分享，所以借这篇文章补上吧。

二、正文

2.1 表象

Jar包冲突作为一个老生常谈的问题，几乎每一个程序员都会遇到。jar包冲突通常发生在程序编译时或运行时。主要分为两类：一类比较直观也是最常见的，在运行时抛出各种异常，还有一类比较隐晦，它不会直接报错，但是程序的行为却和预期不一致，罗列如下：

java.lang.ClassNotFoundException，即找不到指定的java类。
java.lang.NoSuchMethodError，即找不到指定的方法。
java.lang.NoClassDefFoundError，即找不到指定的java类（运行时报错）。
没有异常，但是程序的行为和预期不一致。

如果有上述行为，就很有可能出现了包冲突的问题。

2.2 原理

在正式谈论如何解决这一问题之前，我们不妨先来研究下为什么会出现包冲突的问题。很显然，当我们使用Maven作为包依赖的管理工具的时候，如果我们直接或者间接的引入了groupId和artifactId都相同的包时，maven究竟是怎么选择最终使用哪个version的包来进行打包的呢？

2.2.1 传递依赖冲突

依赖传递：
情形1：如果A依赖B，并且A页依赖C，那么引入A，意味着B和C都会被引入。

image.png

情形2：如果A依赖B，B依赖C，那么引入A，意味着B和C都会被引入。

image.png

Maven引入的传递性依赖机制，一方面大大简化和方便了依赖声明，另一方面，大部分情况下我们只需要关心项目的直接依赖是什么，而不用考虑这些直接依赖会引入什么传递性依赖。但有时候，这种传递性依赖会造成问题。

例如，项目中有这样的依赖关系：A->B->D（1.0）、A->C->D（1.2），D是B和C的传递性依赖，但是两条依赖路径上有两个版本的D，最终哪个D会被Maven解析使用呢？

image.png

Maven最终选择哪个这里暂不给结论，假设最终选择的是D-1.0，但是我们在代码编写的时候使用到了与D1.0中就有的某个类，但是该类在D1.2中新增的某个方法的时候，在编写时代码不会报错，但是一旦编译运行就会报错java.lang.NoSuchMethodError。

2.2.2 依赖调解原则

2.2.2.1 路径最近者优先原则

Maven依赖调解（Dependency Mediation）的第一原则是：路径最近者优先。

如果项目的依赖图如下图所示：D（1.0）的路径长度为2，而D（1.2）的路径长度为3，因此D（1.0）会被解析使用。

image.png

2.2.2.2 第一声明者优先原则

依赖调解第一原则不能解决所有问题。例如下面这个例子，D的两个版本到达A的两条依赖路径长度都为2。那么到底谁会被解析使用呢？在Maven 2.0.8及之前的版本中，结果是不确定的；但是从Maven 2.0.9开始，为了尽可能避免构建的不确定性，Maven定义了依赖调解的第二原则：第一声明者优先，即需要找到在pom文件声明中，依赖B的声明是写在了C的前面还是后面，如果依赖B的声明写在前面，那么D-1.0有效，否则就是D1-2有效。这种原则会解决不确定性的问题，但是有时候我们需要使用到类的功能也会因为这一原则而使用不了。

image.png

2.2.3 小结

在大多数时候，依赖冲突可能并不会对系统造成什么异常，因为Maven始终选择了一个Jar包来使用。但是，不排除在某些特定条件下，会出现类似找不到类的异常，所以，只要存在依赖冲突，在我看来，最好还是解决掉，不要给系统留下隐患。

2.3 解决方案

2.3.1 寻找冲突依赖

2.3.1.1 mvn dependency : tree指令

第一步：找到传递依赖的鬼出在哪里？

dependency:tree是把照妖照，pom.xml用它照照，所有传递性依赖都将无处遁形，并且会以层级树方式展现，非常直观。以下就是执行dependency:tree后的一个输出：

[INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ euler-foundation ---
[INFO] com.hsit:euler-foundation:jar:0.9.0.1-SNAPSHOT
[INFO] +- com.rop:rop:jar:1.0.1:compile
[INFO] |  +- org.slf4j:slf4j-api:jar:1.7.5:compile
[INFO] |  +- org.slf4j:slf4j-log4j12:jar:1.7.5:compile
[INFO] |  +- log4j:log4j:jar:1.2.16:compile
[INFO] |  +- commons-lang:commons-lang:jar:2.6:compile
[INFO] |  +- commons-codec:commons-codec:jar:1.6:compile
[INFO] |  +- javax.validation:validation-api:jar:1.0.0.GA:compile
[INFO] |  +- org.hibernate:hibernate-validator:jar:4.2.0.Final:compile
[INFO] |  +- org.codehaus.jackson:jackson-core-asl:jar:1.9.5:compile
[INFO] |  +- org.codehaus.jackson:jackson-mapper-asl:jar:1.9.5:compile
[INFO] |  +- org.codehaus.jackson:jackson-jaxrs:jar:1.9.5:compile
[INFO] |  +- org.codehaus.jackson:jackson-xc:jar:1.9.5:compile
[INFO] |  \- com.fasterxml.jackson.dataformat:jackson-dataformat-xml:jar:2.2.3:compile
[INFO] |     +- com.fasterxml.jackson.core:jackson-core:jar:2.2.3:compile
[INFO] |     +- com.fasterxml.jackson.core:jackson-annotations:jar:2.2.3:compile
[INFO] |     +- com.fasterxml.jackson.core:jackson-databind:jar:2.2.3:compile
[INFO] |     +- com.fasterxml.jackson.module:jackson-module-jaxb-annotations:jar:2.2.3:compile
[INFO] |     \- org.codehaus.woodstox:stax2-api:jar:3.1.1:compile
[INFO] |        \- javax.xml.stream:stax-api:jar:1.0-2:compile

刚才吹嘘dependency:tree时，我用到了“无处遁形”，其实有时你会发现简单地用dependency:tree往往并不能查看到所有的传递依赖。不过如果你真的想要看所有的，必须得加一个-Dverbose参数，这时就必定是最全的了。

内容太多，眼花缭乱，有没有好法呢？当然有了，加上Dincludes或者Dexcludes制定小包含或者排除的包，dependency:tree就会帮你过滤出来：
引用

Dincludes=org.springframework:spring-tx

过滤串使用groupId:artifactId:version的方式进行过滤，可以不用写全，例如：

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

就会出来asm依赖包的分析信息：

[INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ ridge-test ---
[INFO] com.ridge:ridge-test:jar:1.0.2-SNAPSHOT
[INFO] +- asm:asm:jar:3.2:compile
[INFO] \- org.unitils:unitils-dbmaintainer:jar:3.3:compile
[INFO]    \- org.hibernate:hibernate:jar:3.2.5.ga:compile
[INFO]       +- cglib:cglib:jar:2.1_3:compile
[INFO]       |  \- (asm:asm:jar:1.5.3:compile - omitted for conflict with 3.2)
[INFO]       \- (asm:asm:jar:1.5.3:compile - omitted for conflict with 3.2)
[INFO] ------------------------------------------------------------------------

对asm有依赖有一个直接的依赖(asm:asm:jar:3.2)还有一个传递进入的依赖(asm:asm:jar:1.5.3)

2.3.1.2 Maven依赖结构图

可以使用IDEA提供的方法——Maven依赖结构图，打开Maven窗口，选择Dependencies，然后点击那个图标（Show Dependencies）或者使用快捷键（Ctrl+Alt+Shift+U），即可打开Maven依赖关系结构图

image.png

在图中，我们可以看到有一些红色的实线，这些红色实线就是依赖冲突，蓝色实线则是正常的依赖。

image.png

2.3.1.3 IDEA Maven Helper插件

首先，按照常规的IDEA 插件安装的方式安装插件Maven Helper：

image.png

安装的过程可能会出现下面的报错，是因为插件和idea的版本不兼容，换个插件版本就好了。

image.png

在插件安装好之后，我们打开pom.xml文件，在底部会多出一个Dependency Analyzer选项。

image.png

点开这个选项，找到冲突，点击右键，然后选择Exclude即可排除冲突版本的Jar包。

Conflicts：显示所有的冲突的依赖
All dependencys as List：以列表的形式显示所有的依赖
All dependencys as tree：以树的形式显示所有的依赖

image.png

注意：
同一个jar包可能需要执行多次Exclude操作，因为可能有多处冲突。
执行Exclude之后需要点击"Refresh"刷新一下，才能确定是否依然存在冲突。

2.3.2 处理冲突依赖

2.3.2.1 加载提前

在清楚了Maven的依赖调解规则后，我可以很自然地想到解决方案，就是把我们需要的版本的路径缩短或者声明提前。如下图，比如我们明确需要使用D-1.2，那么我们可以明确在pom依赖中，手动引入D-1.2包，并且将D-1.2的依赖声明写在依赖A的前面即可：

image.png

2.3.2.2 排除依赖

也就是使用exclusions元素声明排除其中一个依赖，exclusions可以包含一个或者多个exclusion子元素，因此可以排除一个或者多个传递性依赖。需要注意的是，声明exclusion的时候只需要groupId和artifactId，而不需要version元素，这是因为只需要groupId和artifactId就能唯一定位依赖图中的某个依赖。换句话说，Maven解析后的依赖中，不可能出现groupId和artifactId相同，但是version不同的两个依赖。

<dependency>
                <groupId>com.alibaba.aecp</groupId>
                <artifactId>logger-formatter</artifactId>
                <version>${logger-formatter.version}</version>
                <exclusions>
                    <exclusion>
                        <groupId>com.taobao.eagleeye</groupId>
                        <artifactId>eagleeye-core</artifactId>
                    </exclusion>
                </exclusions>
            </dependency>

2.3.2.3 升级父节点

使用上面三种方法都有一个前提，那就是你选定的version是可以兼容两个冲突的jar。但是两个jar不兼容的话，针对这种情况，去掉任何一个依赖，都会出现异常。

针对这种情况，去掉任何一个依赖，都会出现异常。接口升级引入了新二方包，导致项目中间接依赖了slf4j-api:1.5.11和slf4j-api:1.7.5，结果这两个包还不兼容，1.7.5新增了一些类，同时把1.5.11中一些方法签名改了，结果这些变动的类和方法都被引用了。最后，使用maven helper查看1.5.11的整个依赖树，找到其父节点，升级其父节点version，这样父节点依赖的slf4j-api的version也会跟着变，找到一个能兼容的版本即可。

image.png

2.3.2.4 全路径冲突

还有一种特殊的冲突，多个dependency的groupID或artifactID不同(或两者都不同)，但包中存在全路径类名相同的类Java类加载器根据classpath加载类时，根据classpath中jar包出现的先后顺序进行查找类并缓存，后面jar包中的类不使用。这个时候的常见异常就是NoSuchMethodException，NoClassDefFoundError，ClassNotFoundException，NoSuchMethodError等。

如果其中一个jar是我们不需要的，那么排除它就行了。但是，如果这个jar被很多dependency依赖，你需要一个个去写exclusions是不是很麻烦。这时我们可以直接在pom中添加一个空依赖(和想要去掉的jar的groupID，artifactID相同，但是version不同的一个空项目打包上传到远程仓库中)。

<!-- ================================================= -->
<!-- 排除依赖 -->
<!-- ================================================= -->
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-nop</artifactId>
    <version>999-not-exist-v3</version>
</dependency>
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>log4j-over-slf4j</artifactId>
    <version>999-not-exist</version>
</dependency>

Maven解决Jar包依赖冲突方案分析

Maven解决Jar包依赖冲突方案分析

一、前言

二、正文

2.1 表象

2.2 原理

2.2.1 传递依赖冲突

2.2.2 依赖调解原则

2.2.2.1 路径最近者优先原则

2.2.2.2 第一声明者优先原则

2.2.3 小结

2.3 解决方案

2.3.1 寻找冲突依赖

2.3.1.1 mvn dependency : tree指令

2.3.1.2 Maven依赖结构图

2.3.1.3 IDEA Maven Helper插件

2.3.2 处理冲突依赖

2.3.2.1 加载提前

2.3.2.2 排除依赖

2.3.2.3 升级父节点

2.3.2.4 全路径冲突