Maven：您如何处理直接依赖和传递依赖？
我试图确定解决以下情况的方法：
有 3 个 Maven 工件：A、B 和 C。B
依赖于 A。（即它使用了 A 的一些代码）
C 依赖于 A 和 B（即它使用了 A 的一些代码和 B 的代码）。
假设我想对 B 和 C 使用相同版本的 A。
应该使用什么方法？
1）在C的pom.xml中将A声明为依赖项。
优点：开发人员很清楚 C 依赖于 A。 缺点：如果A的版本发生变化，需要在多个地方进行更新。 （B 和 C 都）
2) 不要在 C 的 pom.xml 中将 A 声明为依赖项。
赞成/反对：与选项 1 相反。
I'm trying to determine an approach to the following situation:
There are 3 Maven artifacts: A, B, and C.
B depends on A. (i.e. it uses some of A's code)
C depends on both A and B (i.e. it uses some of A's code and B's code).
Assume I want to use the same version of A for both B and C.
What approach should be used?
1) Declare A as a dependency in C's pom.xml.
Pro: It's clear to the developer that C depends on A.
Con: If A's version changes, it needs to be updated in multiple places. (both B and C)
2) Don't declare A as a dependency in C's pom.xml.
Pro/Con: Opposite of option 1.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为你应该在 pom.xml 中声明所有直接依赖项。传递依赖只是自动解决依赖关系的一种便利。
如果更改直接依赖项的版本，传递依赖项可能会随之更改，从而可能破坏模块。该模块应该构建为一个独立的单元，因此应该具有明确定义的依赖关系，不会因外部更改而中断。
我不同意这违反了 DRY 原则，因为 Maven 在单个项目及其 pom.xml 的范围内定义了事物。并且在这个范围内，不存在重复。
更新：
对现有传递依赖项的依赖使得项目本身脆弱，并且还可能导致更复杂的问题，例如何时包含它。
例如，如果 C 对 A 具有编译依赖项，但对 B 有运行时依赖项，那么您现在必须添加依赖项（因为它不再位于您的构建路径中）或将 B 声明为编译，即使它不是。为了清楚起见，有很多话要说。明确定义您的依赖项是什么及其范围，并期望您的依赖项也能执行相同的操作。在大多数情况下，您的依赖项是一个黑匣子，直到它导致问题并且您必须打开它。
I think you should have all direct dependencies declared in your pom. Transitive dependencies are just a convenience for automagically resolving your dependencies dependencies.
If you change a version of a direct dependency, the transitive dependencies will likely change along with it, and thus potentially breaking the module. The module should build as an independent unit and thus should have well defined dependencies that will not break due to external changes.
I disagree that this violates the DRY principal, as maven defines things within the confines of a single project and its pom. And within this scope there is no repetition.
Update:
The reliance on transitive dependencies existing makes the project frail on it's own, and may also lead to more complex issues like when to include it.
For example, if C has a compile dependency on A, but a runtime dependency on B, then you now have to either add the dependency (since it is no longer in your build path) or declare B as compile even though it isn't. There is a lot to be said for clarity. Explicitly define what your dependencies are and what their scope is, and expect your dependencies to do the same. For the most part, your dependency is a black box, until it causes problems and you have to open it.
1）在C的pom.xml中将A声明为依赖项。
2）不要在C的pom.xml中将A声明为依赖项。
我已经把优点和缺点都写下来了，你自己评估一下最适合你的。
Edit#1： 哎呀！我已经改变我的评论了。
Edit#2：在 这个答案。
1) Declare A as a dependency in C's pom.xml.
2) Don't declare A as a dependency in C's pom.xml.
I have written down pros-and-cons, you should evaluate what suits you the best yourself.
Edit#1: tsk! I have switched my comments.
Edit#2: updated the answer after a discussion done on this answer.