在Maven中，是否有任何理由为自己的传递依赖项保留显式依赖项声明？
我已经阅读了一段时间关于Maven中显式和传递（隐式）依赖声明的内容。大多数人倾向于同意，您应该始终显式声明项目所依赖的库，主要是为了避免版本不匹配。
这是完全合理的，但我们应该如何处理我们的内部依赖？我认为绝对没有理由保持模块之间的显式依赖关系，如果它们可以通过传递机制解决的话。
我的用例场景：
- 我的团队在
专业开发软件。少数的micro发布周期，例如：1.1.1、1.1.2、1.3.0等
我的直觉告诉我——摆脱对意大利面条的依赖。有人会证明我错了吗？反应器（依赖项）图非常受欢迎：-）
我的父项目使用以下模块（省略外部依赖项）：
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
问题是：我是否应该在core和logic的pom中将XMLHelper:1.1声明为依赖项。xml？当我使用util模块时，该依赖关系将被自动解析（可传递）。
如果我声明它，我会得到一个更大的pom来维护。
如果我跳过它，当依赖关系随着时间的推移而演变时，我可能会遇到麻烦。
共有1个答案
你有几个问题，所以我会试着回答。
这是完全合理的，但我们应该如何处理我们的内部依赖？
看起来你有一个基于模块的项目。为了减少版本冲突，我建议以下两种可能性之一：
- 在父模块
dependencyManagement部分中放置您的通用依赖项，并为您的版本使用属性
查看此答案以了解更多信息。
我的直觉告诉我——摆脱对意大利面条的依赖。有人会证明我错了吗？
我认为这是一个主观的问题，可能以前有人问过，但我仍然会给出我的意见。
不，我认为你走对了方向。我并不完全赞同“如果正在使用可传递依赖项，就声明它们”的观点。使用maven的最大好处之一是可以获得可传递的依赖项。如果你必须为你所使用的所有东西声明依赖关系，我想你的POM很快就会变成不可管理的野兽。
问题是：我应该将xml-helper： 1.1声明为core和逻辑的依赖项pom.xml?
同样，我倾向于使用dependencyManagement，而不是在每个pom中使用声明。
我希望这有帮助！
-
我是maven的新手。（我已经搜索了几个小时的答案，但没有运气。mvn依赖：复制依赖不能解决我的问题）我需要复制项目的所有依赖项（以jar的形式），如果我的一个jar依赖于另一个工件，也复制该工件。 示例project1 pom。xml： “project1”依赖于project2。人工制品罐子当我使用“mvn依赖项：复制依赖项”时，我得到了project2。人工制品但我没有得到project3。
-
当我有一个包含POM的项目时，例如： 但是我似乎弄错了，Internet上的Maven文档并没有帮助我解决这个问题。 有什么想法吗？
-
我创建了一个Maven项目（可重用库），该项目有许多依赖项（编译时和运行时），它们也可以过渡地依赖于其他许多依赖项。在maven中，我可以在pom中添加依赖项。xml及其可传递依赖关系将自动处理。所以，我将毫无问题地运行。 现在，我有一个非Maven（基于Ant的）项目，上面创建的库（Maven Lib）将使用它。 在这种情况下，运行时间
-
问题内容： 可以运行以了解模块任务的依赖性。有没有办法找到 buildscript依赖 的 传递依赖 ？ 示例： 直接取决于： 可以在MVNRepository上看到。但是，这些工件有其自己的依赖性。有没有找到方法而无需手动遍历整个依赖树的方法？ 为了澄清起见，我正在谈论的类路径由以下方式定义： 问题答案： 您可以使用以下命令： Udacity提供了很棒的Android Gradle 教程，但是您
-
我给ivy添加了一个依赖项（我们称之为a）。在maven central中具有pom文件的xml。Ivy使用ibiblio来解析maven依赖项。添加到常春藤中的依赖项（A）。xml具有可传递依赖项（B）。到目前为止，一切都很好。传递依赖（B）的依赖（C）不能用常春藤来解决。 我在常春藤上定义了一个新的名字。如下所示的xml： 在B的pom文件中，C在编译和测试范围中定义如下： 当我在ivy的缓存