Maven中jar包冲突原理与解决办法
Maven中jar包冲突是开发过程中比较常见而又令人头疼的问题，我们需要知道jar包冲突的原理，才能更好的去解决jar包冲突的问题。本文将从jar包冲突的原理和解决两个方面阐述Maven中jar包冲突的解决办法。
一、Maven中jar包冲突产生原因
MAVEN项目运行中如果报如下错误：
Causedby:java.lang.NoSuchMethodError
Causedby:java.lang.ClassNotFoundException
十有八九是Mavenjar包冲突造成的。那么jar包冲突是如何产生的？
首先我们需要了解jar包依赖的传递性。
1、依赖传递
当我们需要A的依赖的时候，就会在pom.xml中引入A的jar包；而引入的A的jar包中可能又依赖B的jar包，这样Maven在解析pom.xml的时候，会依次将A、B的jar包全部都引入进来。
举个例子：
在SpringBoot应用中导入Hystrix和原生Guava的jar包：
com.google.guava guava 20.0 org.springframework.cloud spring-cloud-starter-netflix-hystrix 1.4.4.RELEASE
利用MavenHelper插件得到项目导入的jar包依赖树：
从图中可以看出Hystrix包含对Guavajar包依赖的引用：Hystrix->Guava，所以在引入Hystrix的依赖的时候，会将Guava的依赖也引入进来。
2、jar包冲突原理
那么jar包是如何产生冲突的？
假设有如下依赖关系：
A->B->C->D1(log15.0)：A中包含对B的依赖，B中包含对C的依赖，C中包含对D1的依赖，假设是D1是日志jar包，version为15.0
E->F->D2(log16.0)：E中包含对F的依赖，F包含对D2的依赖，假设是D2是同一个日志jar包，version为16.0
当pom.xml文件中引入A、E两个依赖后，根据Maven传递依赖的原则，D1、D2都会被引入，而D1、D2是同一个依赖D的不同版本。
当我们在调用D2中的method1()方法，而D1中是15.0版本（method1可能是D升级后增加的方法），可能没有这个方法，这样JVM在加载A中D1依赖的时候，找不到method1方法，就会报NoSuchMethodError的错误，此时就产生了jar包冲突。
注：
如果在调用method2()方法的时候，D1、D2都含有这个方法（且升级的版本D2没有改动这个方法，这样即使D有多个版本，也不会产生版本冲突的问题。）
举个例子：
利用MavenHelper插件分析得出：Guava这个依赖包产生冲突。
我们之前导入了Guava的原生jar包，版本号是20.0；而现在提示Guava产生冲突，且冲突发生位置是Hystrix所在的jar包，所以可以猜测Hystrix中包含了对Guava不同版本的jar包的引用。
为了验证我们的猜想，使用MavenHelper插件打印出Hystrix依赖的jartree：
可以看到：Hystrixjar中所依赖的Guavajar包是15.0版本的，而我们之前在pom.xml中引入的原生Guavajar包是20.0版本的，这样Guava就有15.0与20.0这两个版本，因此发生了jar包冲突。
二、Maven中jar包冲突的解决方案
Maven解析pom.xml文件时，同一个jar包只会保留一个，那么面对多个版本的jar包，需要怎么解决呢？
1、Maven默认处理策略最短路径优先
Maven面对D1和D2时，会默认选择最短路径的那个jar包，即D2。E->F->D2比A->B->C->D1路径短1。
最先声明优先
如果路径一样的话，如：A->B->C1,E->F->C2，两个依赖路径长度都是2，那么就选择最先声明。
2、移除依赖：用于排除某项依赖的依赖jar包
（1）我们可以借助MavenHelper插件中的DependencyAnalyzer分析冲突的jar包，然后在对应标红版本的jar包上面点击execlude，就可以将该jar包排除出去。
再刷新以后冲突就会消失。
（2）手动排除
或者手动在pom.xml中使用
org.springframework.cloud spring-cloud-starter-netflix-hystrix 1.4.4.RELEASE com.google.guava guava
mvn分析包冲突命令：
mvndependency:tree
3版本锁定原则：一般用在继承项目的父项目中
正常项目都是多模块的项目，如moduleA和moduleB共同依赖X这个依赖的话，那么可以将X抽取出来，同时设置其版本号，这样X依赖在升级的时候，不需要分别对moduleA和moduleB模块中的依赖X进行升级，避免太多地方（moduleC、moduleD…）引用X依赖的时候忘记升级造成jar包冲突，这也是实际项目开发中比较常见的方法。
首先定义一个父pom.xml，将公共依赖放在该pom.xml中进行声明：
spring4.2.4 org.springframework spring-beans ${spring.versio}
这样如moduleA和moduleB在引用Spring-beansjar包的时候，直接使用父pom.xml中定义的公共依赖就可以：
moduleA在其pom.xml使用spring-bean的jar包(不用再定义版本)：
org.springframework spring-beans
moduleB在其pom.xml使用spring-bean的jar包如上类似：
org.springframework spring-beans
以上就是日常开发中解决Maven冲突的几个小方案，当然实际开发中jar包冲突的问题可能远远比这个更复杂，需要具体问题具体处理。更多相关Mavenjar包冲突内容请搜索毛票票以前的文章或继续浏览下面的相关文章希望大家以后多多支持毛票票！
声明：本文内容来源于网络，版权归原作者所有，内容由互联网用户自发贡献自行上传，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任。如果您发现有涉嫌版权的内容，欢迎发送邮件至：czq8825#qq.com（发邮件时，请将#更换为@）进行举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。