maven 排除某个类_Maven依赖排除的问题和答案

一、手工排依赖

前言

直接输出冲突的jar文件：mvn dependency:tree -Dverbose > tree.log

Jar包冲突会遇到ClassNotFoundException，NoSuchFieldException，NoSuchMethodException 之类的运行时异常。

处理方法

确定哪个jar包冲突，然后找出冲突了，我这里使用命令

mvn dependency:tree -Dverbose -Dincludes=:

冒号会输出仅包含这个Jar包的依赖树，依赖了这个Jar包的版本一目了然。

例：notify-common冲突，

mvn dependency:tree -Dverbose -Dincludes=:notify-common得到依赖树输出

[INFO] com.taobao.wlb:bis-server:war:1.0-SNAPSHOT

[INFO] +- com.taobao.wlb:bis-core:jar:1.0-SNAPSHOT:compile

[INFO] |  \- com.taobao.logistics:schedule-client:jar:1.1.1:compile

[INFO] |    \- (com.taobao.notify:notify-common:jar:1.8.15:compile - omitted for conflict with 1.8.19.26)

[INFO] \- com.taobao.notify:notify-tr-client:jar:1.8.19.26:compile

[INFO]    +- com.taobao.notify:notify-common:jar:1.8.19.26:compile

[INFO]    \- com.taobao.notify:notify-remoting:jar:1.8.19.26:compile

[INFO]      \- (com.taobao.notify:notify-common:jar:1.8.19.26:compile - omitted for duplicate)

依赖树中所有的叶子节点就是所有的notify-common包，依赖的bis-core中依赖了schedule-client包，它依赖了一个notify-common包，版本是1.8.15，第四行的后面也提示了这个包同其他包有冲突 - omitted for conflict with 1.8.19.26)

而我们的系统依赖的notify-tr-client包所依赖的版本是1.8.19.26，知道这里冲突了，POM删掉依赖，OK。

说明

mvn dependency:tree -Dverbose -Dincludes=:

(1)mvn dependency:tree是maven依赖的分析命令，分析项目依赖，输出依赖树

(2)Dverbose：添加verbose一个环境变量，分析项目依赖时输出明细，输出所有引用，包含间接引用，会很多，so需要第三个参数了

(3)Dincludes=:过滤，排除掉其它不需要的，groupId和artifactId可以只填写一个，一般都会填两个(填写时不包括尖括号)。

二、IDEA排依赖

可用maven helper插件，大项目maven diagram不可用。

pom.xml中右单击 选择Diagrams

在弹出的对话框中，使用Ctrl + F进行搜索

找到有问题的包，右单击就可以排除

三、Maven依赖冲突排查实战

案例实战：引入maven项目的时候，单元测试走不通，报错如下：​

排查步骤如下：

1. 点进去一看，知道是引用jms的依赖的时候，跟到了java.j2ee里面，干掉java.j2ee

2. 打出依赖树 mvn dependency:tree > charles.txt

3. 简单查一下 grep 'java.j2ee' charles.txt

4.跟进charles.txt进行查找，干掉？

5. 继续打依赖树，继续重复此操作

6. 处理完之后继续出现如下错误

7. 寻找com.alibaba.intl.commons.service.AbstractServiceLocator的位置，用排除法来看，确定在

8. 由7确定这是干依赖干多了，可以干掉细粒度的

说明

(1)代码提交之前: mvn compile  编译主程序

ps：mvn clean compile 编译项目，清空项目target目录下的classes目录下的class文件

不用：maven clean install-Dmaven.test.skip，因为如果是release的版本，本地install之后可能会跟仓库出现冲突，因为没往中央仓库deploy之前还是会有修改的可能。

(2)pom父模块设置通用pom依赖的版本号，便于之后管理，干掉pom也通常可以放在父pom中进行

(3)子pom进行一些子模块特有pom的配置

(4)业务场景最好再进行单元测试进行验证

(5)暴力排除冲突的jar能解决大部分问题，但存在ClassNotFoundException的隐患，比如两个二方包强依赖不想下兼容的两个jar，暴力拍掉一个不是很妥