阿里规范 - 六、工程结构 - （二）二方库依赖 - 4. 【强制】二方库的新增或升级，保持除功能点之外的其它 jar 包仲裁结果不变。如果有改变， 必须明确评估和验证。

4. 【强制】二方库的新增或升级，保持除功能点之外的其它 jar 包仲裁结果不变。如果有改变，

必须明确评估和验证。

说明：在升级时，进行 dependency:resolve 前后信息比对，如果仲裁结果完全不一致，那么通过

dependency:tree 命令，找出差异点，进行<exclude>排除 jar 包。

 

maven仲裁机制

参考：https://www.cnblogs.com/zhangfengshi/p/9945504.html

玩过springboot的人都知道  springboot项目中你一般看不到大段的spring相关包 而是像

spring-boot-start一个jar包就包含spring相关的包 包含了具体版本号 ，这其实就是一个版本仲裁的结果，不依赖程序自定义的相关包，这样就不会造成JAR冲突

　　当前maven大行其道，说到第一类Jar包冲突问题的产生原因，就不得不提maven的依赖机制了。传递性依赖是Maven2.0引入的新特性，让我们只需关注直接依赖的Jar包，对于间接依赖的Jar包，Maven会通过解析从远程仓库获取的依赖包的pom文件来隐式地将其引入，这为我们开发带来了极大的便利，但与此同时，也带来了常见的问题——版本冲突，即同一个Jar包出现了多个不同的版本，针对该问题Maven也有一套仲裁机制来决定最终选用哪个版本，但Maven的选择往往不一定是我们所期望的，这也是产生Jar包冲突最常见的原因之一。先来看下Maven的仲裁机制：

• 优先按照依赖管理<dependencyManagement>元素中指定的版本声明进行仲裁，此时下面的两个原则都无效了
• 若无版本声明，则按照“短路径优先”的原则（Maven2.0）进行仲裁，即选择依赖树中路径最短的版本
• 若路径长度一致，则按照“第一声明优先”的原则进行仲裁，即选择POM中最先声明的版本

这里的问题就产生了  按照版本仲裁的原则  比如我需要引入一个jar包 我可能会引入一个较新版本的jar包  但原来三方包里已经有这个jar低版本包 且只支持低版本 高版本还不兼容 这时  按照仲裁原则就会有问题  三方包可能出现运行时异常等问题  所以起步依赖的引入 从根本解决了这个问题！

 

dependency:resolve   dependency:tree  两个命令

参考：https://blog.csdn.net/snowdream86/article/details/9200381 

 

补充：jar包冲突原因分析

参考：https://blog.csdn.net/ycccsdn/article/details/90549347

 

Maven打包排除子jar包  <exclusion>

参考：https://blog.csdn.net/wangb_java/article/details/60330000

 

Maven打包排除某个资源或者目录 <exclude>

 参考：https://www.cnblogs.com/xing901022/p/8080122.html