Maven 依赖管理

摘要

作为开发者，我们一直使用 Maven 来作为版本依赖管理工具，不过我们经常会遇到依赖冲突等问题，我们这边文章就来明确一下 Maven 是如何管理依赖与版本的。

Maven 版本结构

Maven的版本结构使用如下格式：

MajorVersion [ .MinorVersion [ .IncrementalVersion ] ] [ -Qualifier [ -BuildNumber ] ]

MajorVersion, MinorVersion, IncrementalVersion 和 BuildNumber 都需要是数字， Qualifier 是一个字符串。如果你的版本格式不符合这个要求，Maven 会将整个版本看成一个 Qualifier 字符串

版本号也隐含了兼容性

MajorVersion: 修改是非向后兼容的，使用新版本以为要做重大改动 MinorVersion: 修改是向后兼容的，一般表示引入了新功能 IncrementalVersion: 修改是向后兼容的，一般用于bug 修复

Maven依赖的选择策略

假设有一个项目P， 它有如下的依赖图：

那我们在构建的时候，哪些依赖会包含在构建中呢？

这就涉及到Maven的依赖选择策略，Maven 有两条依赖选择规则：

1. 距离根节点最近的依赖会被选择使用 2. 如果同一个依赖有多个版本处在同一层，首先声明的会被选择使用

因此按照上图，项目P的所选择的依赖为 [X, Y, Z 1.0].

但是如果我们想要使用 Z 2.0呢？我们有几种办法可以做：

1. 根据选择策略1， 我们可以直接在 pom 中声明 Z 2.0 依赖 2. 根据选择策略2， 我们可以调整 Y 在 pom 中声明的顺序到 X 之前 3. 我们可以使用 exclude 方式将 Z 1.0 排除出依赖

总结

Maven的依赖管理很灵活，但是当有很多的依赖时，很容易会造成依赖选择的不正确。其实更真实的说法是，Maven 使用的这种依赖选择策略是有问题的，当遇到依赖冲突时，抛出异常由程序员决定选择哪个依赖是更好的选择，Maven 的这种选择依赖的方式运气好一点的在启动或测试时发现，运气不好等到上线甚至埋藏很久才会运行异常，而越晚发现代价就越大。