我们的团队有多个项目;大多数项目只是库。为简单起见,我们假设这些库不相互依赖,并且有一个使用它们的项目,例如:
Project Main:
Project Lib-A:
X (3rd-party library)
Project Lib-B:
X (3rd-party library)
为避免在“Main”中出现意外,我们希望确保我们自己的所有项目都使用相同版本的 3rd-party 库,以便构建“Lib-A”和“Lib-B”使用相同版本的库 X 进行测试。
为了实现这一点,我们使用了一个父 pom,其中包含<dependencyManagement>
详细说明所有相关 3rd 方库的版本以及它们的传递依赖项的部分。这个父 pom 被所有项目继承,即上面示例中的“Main”、“Lib-A”和“Lib-B”。然后每个子 pom 只会使用<dependency>
而不指定任何版本。我们还有Maven 强制插件的 dependencyConvergence 规则,以确保我们没有错过任何项目中的任何库冲突。
问题:增加 X 的版本:'Lib-A' 的开发者将 X 的版本从 1.0 增加到 2.0。所以他在父 pom 中更改 X 的版本,增加 parent 的版本,释放父 pom,并通知来自“Main”的人他们现在应该使用新的父。情况变成这样:
Main - inherits from Parent:2.0 and depends on:
Lib-A:2.0 - inherits from Parent 2.0 and depends on X:2.0
Lib-B:1.0 - inherits from Parent 1.0 and depends on X:1.0
X:2.0 (taken from Parent:2.0 <dependencyManagement> section)
包括“Main”在内的所有内容都构建良好,“maven enforcer plugin”没有检测到任何冲突,因为 X 的版本在 Parent:2.0 中明确指定,“Main”从该版本继承。所以我们发布了'Main'。
哎呀…… Lib-B 从未使用 X:2.0 构建。它有很好的单元测试可以发现问题,但我们从未尝试过。我们忘记更新 Lib-B,尝试使用 X:2.0 并发布它。'Main' 的构建仍然没有问题,并且 Maven 执行器插件从未抱怨过。
问题:我们需要 Maven 来检测是否存在从相同工件但不同主要版本继承的依赖项并导致构建失败。
在我们的例子中,构建必须失败,因为“Main”和“Lib-A”继承自 Parent:2.0,但“Lib-B”继承自 Parent:1.0。
到目前为止我的解决方案(一个 hack):除了继承之外,向所有项目(即“Main”、“Lib-A”和“Lib-B”)添加对父 pom 的显式依赖:
<dependency>
<artifactId>Parent</artifactId>
<type>pom</type>
<version>${project.parent.version}</version>
</dependency>
然后使用<bannedDependencies>
maven enforcer 插件的规则来禁止其他主要的 Parent 版本<dependencyConvergence/>
(如果我们想要失败,即使是次要的 Parent 版本冲突,我们也可以使用它的规则)。
在父 pom 的主要版本冲突时,是否有一种不那么笨拙和麻烦的方法来失败?
可能是我们管理 maven 依赖项的整个方法是错误的,那么推荐的方法是什么?
更新:在放弃之前,尝试按照@JF Mayer 的建议和此处
描述的方式为 maven-enforcer-plugin 编写自己的规则。原因:
- 首先,从依赖项中无法获得父pom信息,至少无法从maven的DependencyGraphBuilder构建的节点中获得
- 好的,我已将我的父 pom 添加为子级的显式依赖项,并尝试使用它
DependencyGraphBuilder
来检测具有不同主要版本的父级的依赖项。没门!可以看出,mvn dependency:tree
它也使用这个类,DependencyGraphBuilder
不提供所有依赖项,因此它不能用于检测依赖项冲突。这就是为什么<dependencyConvergence>
maven 执行器规则使用一个超级弃用DefaultDependencyTreeBuilder
的,甚至已经从 GitHub 和其他任何地方删除 - 对于无故障的自定义解决方案来说,这不是一个好的选择。