Maven 2 Maven：我应该保留或删除声明的依赖项，这些依赖项也是可传递的依赖项吗？

您认为删除maven pom中的所有可传递依赖项是一个好的实践吗

示例：
我的项目取决于A和B。
B也是a的可传递依赖项。
我应该在pom中保留B还是删除它

什么是最好的：
在pom上声明所有已知的罐子，甚至是可传递的罐子，还是只保留顶级罐子

---

这有点主观，但我正在尝试清理一些具有大量可传递依赖项的大型POM（父级和子级）。我希望我的pom尽可能简单，但我也希望它们是可维护的

如果您的项目直接依赖于B，那么即使B是a的可传递依赖项，您也应该保留它。在下一个版本中，a可能不会使用B，您必须重新构造pom.xml

一般来说，Maven依赖项应该反映逻辑项目依赖项。

我宁愿避免声明可传递依赖项，如果有充分的理由，可以将它们明确地包含在pom中。以下是我的论点：

• 我尽量使pom尽可能简单。声明了可传递依赖项后，即使它们被显式使用，Maven pom也会变得更加冗长

通过声明可传递依赖项（即使您明确需要它们）：

• 声明中引入了冗余，因为该信息已经存在于所需工件的pom描述符中

• 如果所需工件的新版本不再依赖于

  可传递依赖项

  ，则必须自己从程序集中删除

  可传递依赖项

  ，前提是明确声明了该

  可传递依赖项

• 可传递性的信息通过显式声明可传递依赖项来处理

在以下情况下明确包含依赖项是有意义的：

• 您有一个或两个依赖项，例如

  C

  和

  D

  ，它们需要不同版本的可传递依赖项

  B

  （或者在项目中需要特定版本的

  B

  ）。在这种情况下，您必须选择

  B

  的一个版本，并明确定义可传递依赖项

  T

  。（*）

结论：

---

我会尽量避免声明，除非明确声明工件（如（*）是有意义的。

谢谢您的回答和链接。我喜欢这样的建议：“反映项目的逻辑依赖性”您不认为应该在这里区分内部依赖性和外部依赖性吗？我也有类似的问题：我仍然不明白为什么我要费心声明我自己模块之间的所有依赖关系。如果API发生变化，项目无法编译，然后，我将修复它，并很可能提高代码的可维护性：）链接与问题/答案之间的关系如何？@AlikElzin kilaka我已将MSTP作为一个插件启动，以分析项目依赖关系，并给出建议，包括哪些直接依赖关系以及删除哪些内容。这正是这里要问的问题。但是，我还没有进入生产版本，因此我将编辑。如果您想参与类似的讨论：