我已经阅读了一段时间有关 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 来维护。
如果我跳过它,当依赖性随着时间的推移而变化时,我可能会遇到麻烦。
最佳答案
你在这里有几个问题,所以我会尽量一一回答。
That is perfectly reasonable, but how should we tackle our internal dependencies?
看起来您有一个基于模块的项目。为了缓解版本冲突,我会建议两种可能性之一:
- 将共同的依赖项放在父模块中
dependencyManagement
部分,并使用您的属性 版本。 - 使用一个基础 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 中声明。
希望对您有所帮助!
关于java - 是否有任何理由在 Maven 中为我自己的传递依赖项保留显式依赖声明?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/20800571/