Maven 依赖

如果使用 Maven 构建产生的构件（例如 Jar 文件）被其他的项目引用，那么该构件就是其他项目的依赖。

依赖配置

配置信息示例：

配置说明：

• dependencies：一个 pom.xml 文件中只能存在一个这样的标签，是用来管理依赖的总标签。
• dependency：包含在 dependencies 标签中，可以有多个，每一个表示项目的一个依赖。
• groupId,artifactId,version(必要)：依赖的基本坐标，对于任何一个依赖来说，基本坐标是最重要的，Maven 根据坐标才能找到需要的依赖。我们在上面解释过这些元素的具体意思，这里就不重复提了。
• type(可选)：依赖的类型，对应于项目坐标定义的 packaging。大部分情况下，该元素不必声明，其默认值是 jar。
• scope(可选)：依赖的范围，默认值是 compile。
• optional(可选)：标记依赖是否可选
• exclusions(可选)：用来排除传递性依赖,例如 jar 包冲突

依赖范围

classpath 用于指定 .class 文件存放的位置，类加载器会从该路径中加载所需的 .class 文件到内存中。

Maven 在编译、执行测试、实际运行有着三套不同的 classpath：

• 编译 classpath：编译主代码有效
• 测试 classpath：编译、运行测试代码有效
• 运行 classpath：项目运行时有效

Maven 的依赖范围如下：

• compile：编译依赖范围（默认），使用此依赖范围对于编译、测试、运行三种都有效，即在编译、测试和运行的时候都要使用该依赖 Jar 包。
• test：测试依赖范围，从字面意思就可以知道此依赖范围只能用于测试，而在编译和运行项目时无法使用此类依赖，典型的是 JUnit，它只用于编译测试代码和运行测试代码的时候才需要。
• provided：此依赖范围，对于编译和测试有效，而对运行时无效。比如 servlet-api.jar 在 Tomcat 中已经提供了，我们只需要的是编译期提供而已。
• runtime：运行时依赖范围，对于测试和运行有效，但是在编译主代码时无效，典型的就是 JDBC 驱动实现。
• system：系统依赖范围，使用 system 范围的依赖时必须通过 systemPath 元素显示地指定依赖文件的路径，不依赖 Maven 仓库解析，所以可能会造成建构的不可移植。

传递依赖性

依赖冲突

1、对于 Maven 而言，同一个 groupId 同一个 artifactId 下，只能使用一个 version。

若相同类型但版本不同的依赖存在于同一个 pom 文件，只会引入后一个声明的依赖。

2、项目的两个依赖同时引入了某个依赖。

举个例子，项目存在下面这样的依赖关系：

这两条依赖路径上有两个版本的 X，为了避免依赖重复，Maven 只会选择其中的一个进行解析。

哪个版本的 X 会被 Maven 解析使用呢?

Maven 在遇到这种问题的时候，会遵循 路径最短优先 和 声明顺序优先 两大原则。解决这个问题的过程也被称为 Maven 依赖调解 。

路径最短优先

依赖链路二的路径最短，因此，X(2.0)会被解析使用。

不过，你也可以发现。路径最短优先原则并不是通用的，像下面这种路径长度相等的情况就不能单单通过其解决了：

因此，Maven 又定义了声明顺序优先原则。

依赖调解第一原则不能解决所有问题，比如这样的依赖关系：A->B->Y(1.0)、A-> C->Y(2.0)，Y(1.0)和 Y(2.0)的依赖路径长度是一样的，都为 2。Maven 定义了依赖调解的第二原则：

声明顺序优先

在依赖路径长度相等的前提下，在 pom.xml 中依赖声明的顺序决定了谁会被解析使用，顺序最前的那个依赖优胜。该例中，如果 B 的依赖声明在 D 之前，那么 X (1.0)就会被解析使用。

排除依赖

单纯依赖 Maven 来进行依赖调解，在很多情况下是不适用的，需要我们手动排除依赖。

举个例子，当前项目存在下面这样的依赖关系：

根据路径最短优先原则，X(1.0) 会被解析使用，也就是说实际用的是 1.0 版本的 X。

但是！！！这会一些问题：如果 C 依赖用到了 1.5 版本的 X 中才有的一个类，运行项目就会报NoClassDefFoundError错误。如果 C 依赖用到了 1.5 版本的 X 中才有的一个方法，运行项目就会报NoSuchMethodError错误。

现在知道为什么你的 Maven 项目总是会报NoClassDefFoundError和NoSuchMethodError错误了吧？

如何解决呢？ 我们可以通过exclusion标签手动将 X(1.0) 给排除。

一般我们在解决依赖冲突的时候，都会优先保留版本较高的。这是因为大部分 jar 在升级的时候都会做到向下兼容。

如果高版本修改了低版本的一些类或者方法的话，这个时候就不能直接保留高版本了，而是应该考虑优化上层依赖，比如升级上层依赖的版本。

还是上面的例子：

我们保留了 1.5 版本的 X，但是这个版本的 X 删除了 1.0 版本中的某些类。这个时候，我们可以考虑升级 D 的版本到一个 X 兼容的版本。

---

著作权归JavaGuide(javaguide.cn)所有 基于MIT协议 原文链接：https://javaguide.cn/tools/maven/maven-core-concepts.html