一、手工排依赖
前言
直接输出冲突的jar文件：mvn dependency:tree -Dverbose > tree.log
Jar包冲突会遇到ClassNotFoundException，NoSuchFieldException，NoSuchMethodException 之类的运行时异常。
处理方法
确定哪个jar包冲突，然后找出冲突了，我这里使用命令
mvn dependency:tree -Dverbose -Dincludes=<groupId>:<artifactId>
冒号会输出仅包含这个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=<groupId>:<artifactId>
（1）mvn dependency:tree是maven依赖的分析命令，分析项目依赖，输出依赖树
（2）Dverbose：添加verbose一个环境变量，分析项目依赖时输出明细，输出所有引用，包含间接引用，会很多，so需要第三个参数了
（3）Dincludes=<groupId>:<artifactId>过滤，排除掉其它不需要的，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，暴力拍掉一个不是很妥
