maven jar包冲突是个老生常谈的话题了。常见的主要问题有两种：
1）maven version不同:
version不同时，maven会自动版本检查产生的不确定性。比如我有一个项目依赖log4j,zookeeper,那么可能配置两个denpendency。但问题是zookeeper里面可能也依赖了log4j,但是依赖的版本我是不知道的。可能和我配置的一致，也可能不一样。此时"聪明"的mvn,会用它认为合理的方式，解析出一个jar包版本。比如"就近原则"，就是谁的dependency依赖的版本的深度“浅”。就用谁的版本。当然还有很多其他规则，在不同版本的maven里，都是不一样的，不建议业务方使用mvn的自动计算jar包版本的机制.
而要使用<dependencyManagement>的形式将jar包版本统一(首推)
或者使用<exclusion>将不需要的版本排除（较麻烦，不推荐）
而需要sa配合的是，最好发布之前，用mvn dependency:tree 打印依赖，做一次依赖分析，将一个项目中依赖同一个artifactId,group,不同version的，提示warning或者不让发布，
当然这个对现有系统影响比较大，推荐搞个warning
2)duplicate class:
这个是影响最大的，就是说两个jar包，可能groupId和artifactId有不相同的地方，这样mvn就不会自动解析版本了，比方有两个asm,都属于asm group,
但有一个asm的artifactId是asm，另外一个个是asm-all.无论系统中使用这两个jar包的版本一样和不一样。maven对此都毫不关心。
因此真正发布的时候，就发布出来了两个jar包，如asm-2.0,asm-all-2.0.如果这两个jar包本身版本功能一致还好，就怕版本一致功能不一致或者版本不一致功能不一致。
这样带来的不确定性就可能引发灾难。(classLoader对于重名的class，具体引用哪一个是不确定的)因为这个问题产生的经典bug最近在组内就出现了好几次
如guava和guava-gwt,json和fast-json,asm和asm-all
这里强烈建议sa加入冲突检查，在mvn的部署脚本中增加对下列字段的grep...如果发现，直接禁止发布。因为很多时候maven的warning我们并不会那么在意，真正上线就会出现问题
Maven build [WARNING] we have a duplicate class
而对于业务方，解决此问题没有什么特别好得方案，只有自行mvn dependency:tree ,检查依赖，手工排除
