在实际开发中,多模块项目常会使用Maven进行包管理。在poml文件中进行包依赖时,常存在引入一个jar包中默认依赖了其他的jar包的情况。这样很容易导致jar包冲突,从而产生一些诡异问题,如版本问题导致的类、方法找不到等。下面我们将聊聊具体关于依赖冲突产生的原因、排查方式以及解决的方案。
举个简单例子,比如一个多模块项目依赖关系如下图。其中bepe-dal引入了common-lib,当bepe-manager模块中引入bepe-dal时,common-lib这个依赖也会被引入到bepe-manager模块中,这个就是依赖传递。
依赖冲突指当模块中引入很多jar包时,如果其中存在着groupId和artifactId 一样,但是version不一样的两个jar包,这就是依赖冲突。那么在应用时会选用哪一个version呢?这就是我们接下来要讨论的冲突解决方式。
当存在groupId和artifactId一致但是version不一致的jar包冲突时,模块会自动选择距离自己路径短的包。如:bepe-manager到common-lib(1.0)的距离为2,bepe-manager到common-lib(2.0)的距离为1,就会选择距离短的common-lib(2.0),这就是最短路径原则。
当冲突包路径距离长度一样时,这个时候就会依据其在pom文件中声明的先后顺序。
在manager模块pom.xml中,如果先引用bepe-common,就会用2.0版本的common-lib。
<dependency> <groupId>com.company.bepe</groupId> <artifactId>bepe-common</artifactId> <version>2.2</version> </dependency> <dependency> <groupId>om.company.bepe</groupId> <artifactId>bepe-dal</artifactId> <version>2.2</version> </dependency>
通过
我们可以借助一些插件工具帮助找出冲突jar的具体位置。下面分享一下我在项目中排查并解决包冲突的两种方式。
Maven提供了Maven-Enforcer-Plugin插件 , 用来校验约定遵守情况,比依赖 jar 包的版本等等。当规则检查不通过的时候则会构建失败。
(1) 在pom.xml中引入该插件
rules内则是定义校验规则,通过配置
<rules> <requireMavenVersion> <version>3.0.4</version> </requireMavenVersion> <!--要求JDK版本)--> <requireJavaVersion> <version>6.0</version> </requireJavaVersion> <bannedDependencies> <!--是否检查传递性依赖(间接依赖)--> <searchTransitive>true</searchTransitive> <excludes> <exclude>junit:junit</exclude> </excludes> <message>must use TestNG</message> </bannedDependencies> </rules>
(2) 配置好插件后进行项目构建,当存在包冲突时会在console中打印出来。
(3) 依据信息便可将不需要的jar包通过
使用IntelliJ IDE的Maven helper插件方便找到和排除冲突的依赖项
(1) command+, 打开工具的设置窗口
(2) 设置搜索中输入plugin
(3) 在Marketplace table页面中搜索Maven Helper,并安装
(4) 重启后即可使用,打开pom文件后,文件下面会多出Dependency Analyzer这一个tab,进入Dependency Analyzer视图之后有三个查看选项,分别是Conflicts(冲突)、All Dependencies as List(列表形式查看所有依赖)、All Dependencies as Tree(树结构查看所有依赖)。通过查看信息后再做出对应的依赖冲突处理。
关于依赖冲突解决方式有三种:最短路径原则、声明优先原则、依赖排除。在没有手动进行依赖排除的情况下,会依据最短路径原则、声明优先原则来选择jar包。关于依赖冲突排查可借助如maven-enforcer-plugin 与Maven Helper 插件。根据实际情况及环境,选择组合最优的解决方案解决依赖冲突问题。