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 ,检查依赖,手工排除