是否有任何理由在 Maven 中为我自己的传递依赖项保留显式依赖项声明？

Question

我已经阅读了一段时间关于 Maven 中的显式与传递（隐式）依赖声明。大多数人倾向于同意您应该始终明确声明您的项目所依赖的库，主要是为了避免版本不匹配。

这是完全合理的，但是我们应该如何处理我们的内部依赖关系？如果可以通过传递机制解决它们，我认为绝对没有理由保持模块之间的显式依赖关系。

我的用例场景：

• 我的团队以major.minor.micro 发布周期开发软件，例如：1.1.1、1.1.2、1.3.0 等...
• 在每个版本中，我们都会增加项目中所有模块的版本控制方案（因此 A:1.0、B:1.0 变为 A:1.1、B:1.1）
• 我们正在使用 reactor 项目，嵌套深度为两层

我的直觉告诉我——摆脱依赖意大利面。有人会证明我错了吗？反应堆（依赖）图非常受欢迎:-)

一个例子：

我的父项目使用以下模块（省略外部依赖）：

Project:1.1   
 - core:1.1
 - +-- util:1.1 
 -   +-- xml-helper:1.1
 - logic:1.1
 - +-- util:1.1 
 -   +-- xml-helper:1.1
 - gui:1.1

问题是：我应该将xml-helper:1.1 声明为core 和logic 的pom.xml 中的依赖项吗？当我使用util 模块时，该依赖关系将被自动解析（传递）。

如果我声明它，我会得到一个更大的 pom 来维护。

如果我跳过它，当依赖关系随着时间的推移而演变时，我可能会遇到麻烦。

Answer 1

这里有几个问题，所以我会尽力一一解答。

这是完全合理的，但我们应该如何处理我们的内部 依赖？

看起来您有一个基于模块的项目。为了减轻版本冲突，我建议以下两种可能性之一：

1. 将您的公共依赖项放在您的父模块中 dependencyManagement 部分，并使用您的属性 版本。
2. 使用基础 pom，并将您的依赖项放在它的 dependencyManagement 部分。

查看this回答以获取更多信息。

我的直觉告诉我——摆脱依赖意大利面。任何人 会证明我错了吗？

我认为这是一个主观问题，may have been asked before 但我仍然会给出我的意见。

没有。我认为你在正确的轨道上。我并不完全赞同“如果你正在使用它们，请声明你的传递依赖”的观点。使用 maven 的一大好处是你可以获得传递依赖。如果你必须为你使用的 everything 声明依赖关系，我想你的 pom 会很快变成难以管理的野兽。

问题是：我应该将 xml-helper:1.1 声明为 核心和逻辑的 pom.xml？

同样，我倾向于使用dependencyManagement，而不是在每个 pom 中声明。

我希望这会有所帮助！