依赖冲突一篇搞定

1 什么是传递依赖冲突

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

dependencies-example-1-e1473694110436-1.jpg

例如项目A有这样的依赖关系:X->Y->Z(1.0)、X->G->Z(2.0),Z是X的传递性依赖,但是两条依赖路径上有两个版本的Z,那么哪个Z会被Maven解析使用呢?两个版本都被解析显然是不对的,因为那会造成依赖重复,因此必须选择一个。


2 你必须知道的依赖调解规则

Maven依赖调解(Dependency Mediation)的第一原则是:路径最近者优先。该例中X(1.0)的路径长度为3,而X(2.0)的路径长度为2,因此X(2.0)会被解析使用。

依赖调解第一原则不能解决所有问题,比如上面这个例子,两条依赖路径长度是一样的,都为2。那么到底谁会被解析使用呢?在Maven 2.0.8及之前的版本中,这是不确定的,但是从Maven 2.0.9开始,为了尽可能避免构建的不确定性,Maven定义了依赖调解的第二原则:第一声明者优先


3 如何解决依赖冲突

3.1 加载提前

在清楚了Maven的依赖调解规则后,我可以很自然地想到解决方案,就是把我们需要的版本的路径缩短或者声明提前。如下图:

direct-child-z-dependencies-example-e1473768217230-1.jpg

3.2 排除依赖

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

            
                com.alibaba.lava
                lava-core
                3.0.1-YUJUN-SNAPSHOT
                
                    
                        org.mybatis
                        *
                    
                    
                        jakarta.commons.collections
                        com.alibaba.external
                    
                    
                        mcms.client
                        com.alibaba.intl.sourcing.shared
                    
                
            

3.3 升级父节点

使用上面三种方法都有一个前提,那就是你选定的version是可以兼容两个冲突的jar。但是两个jar不兼容的话,针对这种情况, 去掉任何一个依赖,都会出现异常。这时,我们查看整个依赖树,找到其父节点,升级其父节点version。


4 全路径冲突

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

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

            
            
            
            
                org.slf4j
                slf4j-nop
                999-not-exist-v3
            
            
                org.slf4j
                slf4j-log4j12
                999-not-exist-v3
            
            
                org.slf4j
                log4j-over-slf4j
                999-not-exist
            

5 如何快速发现依赖冲突

5.1 常用的Maven命令

5.1.1 mvn dependency:list

Maven会自动解析所有项目的直接依赖和传递性依赖,并且根据规则正确判断每个依赖的范围,对于一些依赖冲突,也能进行调节,以确保任何一个构件只有唯一的版本在依赖中存在。在这些工作之后,最后得到的那些依赖被称为已解析依赖(Resolved Dependency)。可以运行如下的命令查看当前项目的已解析依赖:

mvn dependency:list

5.1.2 mvn dependency:tree

能够查看依赖树,通过这棵树能够很清楚的看到某个依赖是通过哪条路径引入进来的。

mvn dependency:tree -Dverbose

详细显示依赖信息,把版本冲突中被抛弃,重复的都显示出来,便于排查问题。

mvn dependency:tree -Dverbose --> a.txt

将结果保存到文件中

mvn dependence:tree -Dverbose -Dincludes=org.mybatis:mybatis

includes指的是想看哪些信息。

参数格式[groupId]:[artifactedId]

5.1.3 mvn dependency:analyze

可以帮助分析当前项目的依赖。

(1)Used undeclared dependencies

意指项目中使用到的,但是没有显式声明的依赖,这里是spring-context。这种依赖意味着潜在的风险,当前项目直接在使用它们,例如有很多相关的Java import声明,而这种依赖是通过直接依赖传递进来的,当升级直接依赖的时候,相关传递性依赖的版本也可能发生变化,这种变化不易察觉,但是有可能导致当前项目出错。例如由于接口的改变,当前项目中的相关代码无法编译。这种隐藏的、潜在的威胁一旦出现,就往往需要耗费大量的时间来查明真相。因此,显式声明任何项目中直接用到的依赖。

(2)Unused declared dependencies

意指项目中未使用的,但显式声明的依赖,这里有spring-core和spring-beans。需要注意的是,对于这样一类依赖,我们不应该简单地直接删除其声明,而是应该仔细分析。由于dependency:analyze只会分析编译主代码和测试代码需要用到的依赖,一些执行测试和运行时需要的依赖它就发现不了。很显然,该例中的spring-core和spring-beans是运行Spring Framework项目必要的类库,因此不应该删除依赖声明。当然,有时候确实能通过该信息找到一些没用的依赖,但一定要小心测试。

5.1.4 mvn enforcer:enforce

首先,需要将下面的插件添加到pom.xml中:


    
        org.apache.maven.plugins
        maven-enforcer-plugin
        1.4.1
        
            
        
    

注意这里配置的rules规则,它有很多内置的规则:

  • dependencyConvergence:确保依赖只有一个版本存在于项目中,否则build报错,报错信息中就告诉你哪些有冲突了。

  • banDuplicateClasses:找到重复的类。

  • bannedDependencies:配置不允许使用的jar。例如只能使用log4j2,不允许使用log4j1。

5.2 IDEA maven helper插件

当Maven Helper 插件安装成功后,打开项目中的pom文件,下面就会多出一个试图

20190217233212.png

切换到此试图即可进行相应操作:

  • Conflicts(查看冲突)

  • All Dependencies as List(列表形式查看所有依赖)

  • All Dependencies as Tree(树形式查看所有依赖)

20190217233339.png

你可能感兴趣的:(依赖冲突一篇搞定)