Maven 依赖原则和依赖冲突
1、maven依赖原则
1.1 依赖路径最短优先原则
工程A的依赖关系如上图，maven会根据依赖路径最短优先原则，选择X（2.0）
1.2 pom文件中申明顺序优先
如果A的依赖关系如上图，X(1.0)和X(2.0) 路径距离一样的话，maven会根据A的pom文件声明的顺序加载，如果先声明了B，后声明了C，那就最后的依赖就会是X(1.0)。
1.2 3 覆写优先
- 子Pom内声明的优先于父 Pom 中的依赖。
- 同Pom内出现不同版本的相同类库时，后声明的会覆盖先声明的。也就是在同一个Pom里配置了相同资源的不同版本的直接依赖，后配置的覆盖先配置的
2 如何排除依赖
2.1 什么是传递性依赖
比如当我们项目中，引用了A的依赖,A的依赖通常又会引入B的 Jar 包，B可能还会引入C的 Jar 包。
这样，当你在 pom.xml 文件中添加了A的依赖，Maven 会自动的帮你把所有相关的依赖都添加进来。
就这样一层层的，Maven 会自动的帮你把所有相关的依赖都添加进来。传递性依赖会给项目引入很多依赖，简化项目依赖管理，但是也会带来问题。
最明显的就是容易发生依赖冲突。
2.2 如何排除依赖
这种情况下，想要解决依赖冲突，可以靠升级/降级某些依赖项的版本，从而让不同依赖引入的同一类库，保持一致的版本号。另外，还可以通过隐藏依赖、或者排除特定的依赖项来解决问题。
2.2.1 exclusions 标签
Exclusions是主动断开依赖的资源，被排除的资源无需指定版本
也就是说可以包含一个或者多 Exclusion 子元素，因此可以排除一个或者多个传递性依赖。需要注意的是，声明 Exclusion 的时候只需要 Groupld 和 Artifactld ,而不需要要 Version 元素。
用法示例：
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
<version>5.1.8.RELEASE</version>
<exclusions>
<!-- 排除web包依赖的beans包 -->
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
</exclusion>
</exclusions>
</dependency>
2.2.2 optional 标签
该标签即是“隐藏依赖”的开关,指对外隐藏当前所依赖的资源
true：开启隐藏，当前依赖不会向其他工程传递，只保留给自己用；
false：默认值，表示当前依赖会保持传递性，其他引入当前工程的项目会间接依赖。
用法示例：
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-aop</artifactId>
<version>5.1.8.RELEASE</version>
<optional>true</optional>
</dependency>
2.2.3 exclusions标签和optional标签的区别
- A依赖B,B依赖C , C 通过依赖传递会被 A 使用到，现在要想办法让 A 不去依赖 C
- ( A是demo01,B是demo02,C是aop)
- 可选依赖是在B上设置 , A 不知道有 C 的存在，代表这个依赖是否需要被发现。这种适用于可以修改B(02)的配置文件的情况下 先看默认情况，也就是false
改为 true 后
- 排除依赖是在A上设置 , A 知道有 C 的存在，主动将其排除掉。代表这个依赖已经被发现，但自己是否需要引用。这种适用于不能修改B的配置文件的情况下
3 Maven 聚合工程 统一管理版本
聚合工程，即是指：一个项目允许创建多个子模块，多个子模块组成一个整体，可以统一进行项目的构建。要弄明白聚合工程，得先清楚“父子工程”的概念：
- 父工程：不具备任何代码、仅有pom.xml的空项目，用来定义公共依赖、插件和配置；
- 子工程：编写具体代码的子项目，可以继承父工程的配置、依赖项，还可以独立拓展。
而Maven聚合工程，就是基于父子工程结构，来将一个完整项目，划分出不同的层次，这种方式可以很好的管理多模块之间的依赖关系，以及构建顺序，大大提高了开发效率、维护性。
为了防止不同子工程引入不同版本的依赖，在父工程中，统一对依赖的版本进行控制，规定所有子工程都使用同一版本的依赖，可以使用<dependencyManagement>标签来管理。
- <dependencies>：定义强制性依赖，写在该标签里的依赖项，子工程必须强制继承；
- <dependencyManagement>：定义可选性依赖，该标签里的依赖项，子工程可选择使用。
子工程在使用中已有的依赖项时，不需要写版本号，版本号在父工程中统一管理，这样做的好处在于：以后为项目的技术栈升级版本时，不需要单独修改每个子工程的POM，只需要修改父POM文件即可，减少了版本冲突的可能性。
4 定位冲突
# 4.1 maven show dependencies
IDEA中自带一个功能，maven show dependencies，右击pom文件可以调出，或者右上角的快捷键也可以调出
maven show dependencies，会为我们显示一棵maven的依赖树：
蓝色箭头是正常的依赖关系，红色箭头是依赖冲突关系。
如果依赖太多，ctrl+F可以弹出依赖列表，在其中可以选择想定位到的依赖：
很遗憾的是maven show dependencies这种方式的场景实在是有限，正常的稍微上一点体量的项目，依赖树都会很大，用这种方式会把人看傻。
这里我随便拿一个博主经历过的项目上的依赖树拿出来，是长这样的：
这种依赖树，根本就没办法去看，就算定位到了，依赖路径的线条你都找不清楚。所以就没有办法了吗？当然是有的，这就是IDEA的一款插件，我们的maven依赖冲突分析利器——maven helper。
# 4.2 Maven Helper 插件分析jar包冲突
如果你的项目中依赖许许多多的 Jar ，肉眼排查就没那么方便了，这里推荐一个 Maven 管理插件
在 Pom 文件中看到 Dependency Analyzer标志，说明 Maven Helper 插件就安装成功了
点击 Dependency Analyzer 之后就会进入到下面的页面
从图中可以看出有哪些jar存在冲突，存在冲突的情况下最终采用了哪个依赖的版本。标红的就是冲突版本，白色的是当前的解析版本。
如果我们想保留标红的版本，那我们可以标白区域右击选择排除(Exclude)即可。