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.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 的存在，主动将其排除掉。代表这个依赖已经被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)即可。

到此这篇关于Maven 依赖原则和依赖冲突的使用小结的文章就介绍到这了,更多相关Maven 依赖原则和依赖冲突内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论