概述

使用Maven可以很方便地管理项目中的依赖，但是由于Maven中的依赖具有传递性，会导致我们项目中的错综复杂，最典型的就是由依赖冲突发生的ClassNotFoundException和NoSuchMethodException

什么是依赖冲突

当项目中引用了某个jar包的不同版本，就会发生依赖冲突。假设项目A的依赖关系如下：

A
├── B
│   └── C
│       └── D 2.0
└── E
    └── D 1.0

A中间接依赖了两个D，版本分别是D2.0跟D1.0，路径分别是A->B->C-D2.0,A->E->D1.0，此时就产生了依赖冲突，因为项目在打包运行的时候，只能使用一个D依赖，即只能使用D2.0或D1.0其中之一

Maven 如何解决依赖冲突

知道什么是依赖冲突后，我们来看看Maven是如何解决该问题的。在Maven的依赖处理机制中，使用最近定义(nearest definition)原则来处理包冲突问题，如果项目最终依赖于多个相同artifactid的多个版本，则会使用依赖树中最先定义的那个版本（广度优先）

因为A->E->D1.0的依赖路径比A->B->C->D2.0短，所以最终会使用D1.0作为项目的依赖版本

依赖冲突产生的问题

还是以上面的依赖关系为例

A
├── B
│   └── C
│       └── D 2.0
└── E
    └── D 1.0

假设D1.0跟D2.0都有类A，两个版本中的方法如下

        D1.0                         D2.0
 __________________           __________________
|      classA      |         |      classA      |
|__________________|         |__________________|
|+ method1()       |         |+ method1()       |
|                  |         |+ method2()       |
|__________________|         |__________________|

此时，当C调用了calssA中的method2()方法，就会报NoSuchMethodException，因为此时依赖的版本为D1.0，D1.0中并没有该method2()方法

NoSuchMethodException 问题解决

知道了NoSuchmethodException产生的原因后，解决的方法很简单，只要将D1.0的依赖改为D2.0就可以了，可以在A的pom文件中加入D2.0依赖，这样项目的依赖树就变为

A
├── B
│   └── C
│       └── D 2.0
└── E
|   └── D 1.0
│
└── D 2.0

此时，依赖路径A->D2.0最短，根据Near Definition原则，项目的依赖版本就变为D2.0了

除了上面的方法外，还可以在E的pom使用exclusion，移除掉D1.0，这样项目中就只剩D2.0了

<dependency>
    <groupId>xxx</groupId>
    <artifactId>E</artifactId>
    <version>xxx</version>
    <exclusions>
    <exclusion>
        <artifactId>D</artifactId>
        <groupId>xxx</groupId>
    </exclusion>
</exclusions>
</dependency>

依赖隔离

使用D2.0替换D1.0的前提是D做了向下兼容，假设升级了D2.0后，并不能兼容原先的D1.0，那么此次升级就有可能引发别的问题，那么有什么方法能使D1.0跟D2.0同时存在呢，即模块E还是使用D1.0依赖，模块C用2.0依赖。答案就是依赖隔离技术

由于依赖隔离设计到的东西比较多，这里不做介绍，之后会额外写一篇文章介绍依赖隔离，感兴趣的可以关注我的公众号：huangxy，文章写好会第一时间推送

参考

https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
https://dzone.com/articles/solving-dependency-conflicts-in-maven