依赖冲突解决办法
maven 的价值
Java开发中，jar的管理由maven来管。maven做的事情：
jar统一管理： jar 包统一管理在仓库中。统一管理自然要给每个jar包进行“编址”，它主要采用 groupId+artifactId+version三级寻址方案（当然也有classifier）。统一管理带来好处的同时，带来了麻烦，麻烦是仓库是“单点”，为了避免这个瓶颈，maven 客户端配置可以支持镜像仓库（mirrors）机制。依赖传递： 当我们的程序依赖A，我们引用A就好；但是实际上A又依赖B和C，我们不用再琐碎的依赖B和C了，这个maven会解析A中的pom.xml，并传递的拉取子级依赖。
“依赖传递”让开发者省去很多琐碎的心思。但它方便的同时，可能带来一些麻烦——依赖冲突。
依赖冲突
所谓“依赖冲突”如下图所示：
图中，我们的程序依赖A，那么我们在pom.xml中配置：
org.example
A
${version}
实际上，A它依赖B和C （这个在A的pom.xml中会有描述）。B再依赖X和Y；C依赖Y和Z。其中Y是B和C的共同依赖，只不过B依赖Y的1.0版本，而C依赖Y的2.0版本。
问题来了：maven应该选择Y的1.0版本，还是2.0版本呢？
答案：maven肯定需要给出一个决策顺序机制，来解决这个依赖冲突的问题。但这个机制即使我们知道了，实际工作中还是经常忘记，索性不想知道了。我们把握3点：
- 依赖冲突发现：能够查看出当前项目中存在依赖冲突。
- 决策结果查看：我不想知道决策顺序是什么，但我必须知道决策结果。
- 调整决策结果: 可以让我们手动干预决策结果。比如上图的，我们可以自由选择Y-1.0.jar 还是 Y-2.0.jar 。
当然如果maven足够智能那当然更好，它能自动选择一个满足运行的决策，并把这个决策告诉ClassLoader。
顺便说一下，有没有可能冲突不可调和呢？当然可能，完全取决于Y是否遵守发版的基本原则：新版本兼容老版本。
如何实战上述的3点呢？ 用个Java开发过程中，经常可能发生的实际例子——slf4j的依赖冲突。
slf4j 实例
运行异常
程序运行时，出了个这样的异常：
Caused by: java.lang.NoSuchMethodError: org.slf4j.helpers.MessageFormatter.format(Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/String;
at org.slf4j.impl.Log4jLoggerAdapter.info(Log4jLoggerAdapter.java:318)
at org.hibernate.annotations.common.Version.(Version.java:37)
这个异常说的是hibernate的annotations的某个类，在用slf4j输出日志的时候，发现NoSuchMethodError异常：org.slf4j.helpers.MessageFormatter类缺少format(Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/String方法。
我们ctrl+shift+T在Eclipse查看下org.slf4j.helpers.MessageFormatter类的，并ctrl+O找到format方法，发现的确没有参数为format(String[] , Object[])的方法，有的只是format(String, Object)方法。如下图所示：
的的确确slf4j缺少了那个方法。接着我们应该看看这个项目中有多少个jar依赖了slf4j，再仔细看看hibernate的annotations依赖的slf4j的版本。
依赖冲突发现
“依赖冲突发现”有两个技能，一个是可视化，另一个是命令行。
可视化技能：在Eclipse选择pom.xml，查看“Dependency Hierarchy”：
可以看到hibernate-annotations依赖的版本是1.5.8，而xmemcached依赖的是1.5.6。maven现有决策机制把1.5.6排在前面，hibernate的显示“omitted for conflict with 1.5.6”。
到这可以看出，问题应该出在：hibernate原本要依赖高版本的1.5.8，而却被决策依赖到1.5.6了。
顺便说一下，命令行方式：
mvn dependency:tree // 显示依赖结构
mvn dependency:tree -Dverbose // 详细显示，路径更深
mvn dependency:tree -Dverbose -Dincludes=org.slf4j // 如果太多，可以筛选
mvn dependency:tree -Dverbose -Dincludes=org.slf4j -Dexcludes=org.hibernate // 还可以排除
决策结果查看
在“在Eclipse选择pom.xml，查看‘Dependency Hierarchy’”的图片中已经可以看到决策结果了。被忽略的会显示“omitted for conflict with XXX”。
当然也可以在JAVA启动的时候，增加JVM参数：-verbose:class。这样ClassLoader加载Class的时候就会有日志输出。
在一堆日志中，查找slf4j：
[Loaded org.slf4j.LoggerFactory from file:~/.m2/repository/org/slf4j/slf4j-api/1.5.6/slf4j-api-1.5.6.jar]
调整决策结果
排除 xmemcached 依赖的 slf4j：
界面操作完后，对应的pom.xml被自动编辑为（注意exclusion标签）：
com.googlecode.xmemcached
xmemcached
${xmemcached.version}
slf4j-api
org.slf4j
调整后，用上面说的方法，再次验证一下决策结果。
全局排除
有了exclusion机制，冲突问题就基本能解决了（当然前提是冲突的那个jar，新版本能兼容老版本）。接着思考一个问题：我们刚刚从xmemcached排除了slf4j，以后其他人引用一个新包，比如叫abc.jar，它也依赖了slf4j，我们再排除一遍？要知道slf4j如此流行，许多包都会依赖它，于是我们每次加一个新jar都要去排除一遍？我们可以这么勤快去做。但万一哪次没排除，我们还一时不好发现，因为即便新jar引入一个低版本的slf4j，也得在运行时运行到需要高版本的分支问题才能暴露。我们会反反复复的去折腾这个日志问题。
于是我们想：
- 版本去留：有没有一种机制能一次性排除slf4j，排除其他所有版本，只保留我们给定的版本”。
- 严禁引入: slf4j有许多binding实现，可以logback，也可以log4j，还可以其他。假设我们期望选择log4j，后面的人一不小心偷偷引入logback应该被发现，被禁止。
社区里有先行者为大家做了插件：maven-enforcer-plugin，里面有个配置项bannedDependencies来管理这些。例如：
org.apache.maven.plugins
maven-enforcer-plugin
1.4.1
default-enforce
enforce
org.slf4j:*
ch.qos.logback:*
org.springframework:*
org.slf4j:slf4j-api
org.slf4j:slf4j-log4j12
org.springframework:*:${spring.version}
通过slf4j，在通过slf4j-api和log4j12，如果需要指定版本，可以
配置完后，执行mvn validate或者mvn clean package的时候，如果违背了上述规则，就会报告：
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.BannedDependencies failed with message:
Found Banned Dependency: ch.qos.logback:logback-classic:jar:1.1.2
Found Banned Dependency: org.slf4j:log4j-over-slf4j:jar:1.7.7
Found Banned Dependency: ch.qos.logback:logback-core:jar:1.1.2
Found Banned Dependency: org.springframework:spring-test:jar:2.5.6
Use 'mvn dependency:tree' to locate the source of the banned dependencies.
这样我们再通过前面讲的exclusion机制来排除。
提醒
maven-enforcer-plugin不会自动排除，但会提供一个规则检测机制。然后谁加入，谁排除。
遭遇“流氓”
按理有了maven-enforcer-plugin冲突问题都可以很好解决。但笔者接下来要分享一个“流氓”事件——不遵守maven发布规则的人发布的jar。
如下一段非常简单的代码，就是用slf4j输出一行日志：
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class LogDemo {
private static final Logger LOG = LoggerFactory.getLogger(LogDemo.class);
public static void main(String[] args) throws Exception {
LOG.info("HelloWorld");
}
}
运行时，报了一个异常：
SLF4J: This version of SLF4J requires log4j version 1.2.12 or later. See also http://www.slf4j.org/codes.html#log4j_version
Exception in thread "main" java.lang.NoSuchFieldError: TRACE
at org.apache.log4j.Logger.isTraceEnabled(Logger.java:209)
at org.slf4j.impl.Log4jLoggerAdapter.isTraceCapable(Log4jLoggerAdapter.java:83)
at org.slf4j.impl.Log4jLoggerAdapter.(Log4jLoggerAdapter.java:78)
at org.slf4j.impl.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:68)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:277)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:288)
at LogDemo.(LogDemo.java:8)
说的是“SLF4J 绑定 log4j时，对 log4j 的版本要求是 1.2.12 或 以上”。
我们用上文提到过的Eclipse的“Dependency Hierarchy”查看log4j：
如上图所示，log4j的版本是1.2.17 > 1.2.12，而且这个log4j还不是我们引入的，而是slf4j的log4j官方绑定 slf4j-log4j12 间接引入的（它的pom里面依赖了log4j）。显然这不会有版本问题。但的的确确就是异常了。
这时可以用 增加JVM参数 -verbose:class 来看加载的类。
再给一个简单的方法，那个异常说是org.apache.log4j.Level类有没有Trace属性，在Eclipse查下org.apache.log4j.Level`类（Ctrl+Shift+T）。会发现有两个jar``包都含有这个类。
第2个是我们想要的log4j，第1个是一个名叫"XXXclient-999-4.2.0.jar"的包里的log4j。看看这个jar，为了直观，我用可视化的方式看（你也可以 ``jar tvf XXXclient-999-4.2.0.jar | grep org.apache.log4j）：
没见过这么“流氓”的，依赖方式不是走pom.xml的dependency，而是直接log4j的源代码打包进来，必然导致maven管理不到它。
解决办法，把那个jar中关于log4j的东西删了，再手动打包发布一个新的4.3.0版本。
tar xvf XXX-client-4.2.0.jar
rm -rf org/apache
rm -rf log4j.properties
tar cvf XXX-client-4.3.0.jar .
mvn install:install-file -Dfile=XXX-client-4.3.0.jar -DgroupId=XXX.sdk -DartifactId=XXX-client -Dpackaging=jar -Dversion=4.3.0
如需发布到远程，请用deploy命令。
这个问题不是本文的主题，只顺带提一下。