Maven 依赖冲突介绍

587 阅读2分钟

概述

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

什么是依赖冲突

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

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

A中间接依赖了两个D,版本分别是D2.0D1.0,路径分别是A->B->C-D2.0,A->E->D1.0,此时就产生了依赖冲突,因为项目在打包运行的时候,只能使用一个D依赖,即只能使用D2.0D1.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.0D2.0都有类A,两个版本中的方法如下

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

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

NoSuchMethodException 问题解决

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

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

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

除了上面的方法外,还可以在Epom使用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.0D2.0同时存在呢,即模块E还是使用D1.0依赖,模块C2.0依赖。答案就是依赖隔离技术

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

参考