背景介绍
最近遇到了这样一个问题，我们有一个 jar 包 common-tool，作为基础工具包，被各个项目在引用。突然某一天发现日志很多报错。
一看是 NoSuchMethodError，意思是 DisJunction 里 init 方法没找到，但是我检查了代码是有这个方法的啊。
问题定位
当时百度了一下，都说这种情况一般是 jar 包冲突了，但是本地看来下没有 jar 包版本都一致，没有冲突啊，百思不得其解。于是写了个代码看看这个报找不到方法的类到底有没有这个方法。
Constructor[] constructors = Disjunction.class.getConstructors();
for (Constructor constructor:constructors){
//查看类的构造器方法
log.error("find monitor bug:{}",constructor);
}
Class targetclass = Disjunction.class;//可以用自己想知道的类替换
String className = targetclass.getName();
className = className.replace('.', '/');
String resource = "/" + className + ".class";
URL url = targetclass.getResource(resource);
//查看类的全路径
log.error("find monitor bug:{}",url.getFile());
打印出来后发现类全路径竟然不是我的包里的，是一个 agent.jar 里面的。
问了下才知道原来是运维添加了一个 agent 到线上环境，里面的 byte-buddy 依赖和我的冲突了。
如果是本地冲突的话，也可以使用 IDEA 里的 Maven Helper 插件，它可以清晰的指出某个包被哪几个包依赖。
解决方案：
在看解决方案之前先来回顾一下Maven的依赖原则：
- 最短路径优先
即如果我 A->B->C->X1.0，D->E->X2.0，我项目里引入了 A 和 D，那么我的 X 版本是用的 2.0，因为 X2.0 路径最短。
- 申明顺序优先
如果 A-B-X(1.0) ，A-C-X(2.0) 这样的路径长度一样怎么办呢？这样的情况下，maven 会根据 pom 文件声明的顺序加载，如果先声明了 B，后声明了 C，那就最后的依赖就会是 X(1.0)
解决方案 1：
maven 依赖的顺序是路径优先，所以我们可以在项目的 pom 文件里直接申明版本，这样就比项目里的引入的 jar 包里再引入的依赖优先级要高些。
这种方案的缺点就是因为我这个基础 jar 包好几个项目再用，需要每个项目都要修改。
解决方案 2：
使用 maven 插件 maven-shade-plugin
maven-shade-plugin
package
shade
//替换的范围，只替换下面两个包 net.bytebuddy:byte-buddy
net.bytebuddy:byte-buddy-agent
true
// 将net.bytebuddy依赖重命名为cn.mmc.net.bytebuddy
net.bytebuddy
cn.mmc.net.bytebuddy
这种做法就是将原有依赖的 jar 包都重命名一下，比如里面的类是 net.bytebuddy.DisJunction，用这个插件后就变为了
cn.mmc.net.bytebuddy.DisJunction，这样类的全路径不一样，就彻底杜绝了依赖冲突的情况。
另外上面的 includes 是指仅指定替换某些依赖里包名是 net.bytebuddy，否则所有包含了 net.bytebuddy 的都会被重命名，这样打出来的 jar 包就会非常大。
总结
为了一劳永逸，我使用了第二种方案 maven-shade-plugin 的方式，发布之后依赖冲突的问题就解决了。