java - 是否有任何理由在 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)
• 我们正在使用 react 器项目，嵌套最深两层

我的直觉告诉我 - 摆脱依赖意大利面条。有人会证明我错了吗？ react 堆(依赖项)图非常受欢迎:-)

一个例子:

我的父项目使用了以下模块(省略了外部依赖):

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

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

That is perfectly reasonable, but how should we tackle our internal dependencies?

看起来您有一个基于模块的项目。为了缓解版本冲突，我会建议两种可能性之一:

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

检查 this回答更多信息。

My gut is telling me - get rid of the dependency spaghetti. Anyone will prove me wrong?

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

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

The question is: should I declare xml-helper:1.1 as a dependency in core's and logic's pom.xml?

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

希望对您有所帮助!