是否有任何理由在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's和logicpom.xml中声明为依赖吗？当我使用util模块时,该依赖关系将自动解决(传递).

如果我宣布它,我会得到一个更大的pom来维持.

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

Answer 1

你在这里有几个问题，所以我会尽量一一回答。

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

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

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

查看此答案以获取更多信息。

我的直觉告诉我 - 摆脱对意大利面的依赖。有人会证明我是错的吗？

我认为这是一个主观问题，之前可能有人问过，但我仍然会给出我的意见。

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

问题是：我应该将 xml-helper:1.1 声明为 core 和 logic 的 pom.xml 中的依赖项吗？

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

我希望这有帮助！