如果它们来自父级的其他子模块，我是否应该依赖Maven中的传递依赖项？

Question

假设我们正在研究抵押子模块，并且直接Google Guava在模块代码中使用这些类，但是的依赖关系guava是在同一父对象下的其他子模块中定义的，并且只能通过对“投资”模块：

banking-system (parent pom.xml)
|
|-- investment (pom.xml defines <dependency>guava</dependency>)
|
|-- mortgage (pom.xml defiens <dependency>investment</dependency>)

我们还应该<dependency>在抵押pom.xml中为Guava 放置一个吗？

缺点看起来像我们pom.xml中的副本，优点是：如果开发“投资”的人会丢弃番石榴，那么它不会阻止我们的抵押子模块成功构建。

如果是，那么<version>我们指定什么方法？（<dependencyManagement>在父pom中没有+ ？）

如果是，那么我们应该<provided>在某个模块中使用范围吗？

注意：请记住，我是在特定情况下询问模块具有共同的父pom（例如，作为一个整体的应用程序）。

想象一下，也许这种结构不是最好的例子：

banking-app
    banking-core (dep.on: guava, commons, spring)
    investment (dep.on: banking-core)
    mortgage (dep.on: banking-core)

Investment使用Spring时仍应该显式声明Spring @Component，如果使用Guava则声明Guava LoadedCache？

Answer 1

我们直接在模块代码中使用Google Guava类，但是番石榴的依赖关系是在同一父对象下的其他子模块中定义的，我们只能通过对“投资”模块的传递依赖来访问Guava类[...]我们还应该在抵押pom.xml中添加一个到Guava吗？

是的，您应该在模块中声明Google Guava依赖项，并且不要期望它可以作为传递依赖项使用。即使它与当前版本兼容，在更高版本的直接依赖项中也可能不再如此。

如果您的代码依赖于一个模块，则您的代码应仅直接依赖于此模块的类，而不应依赖于此模块的传递依赖。如您所述，不能保证将来的投资模块将继续依赖Guava。您需要在父级的pom.xml或模块本身中指定此依赖关系，以确保在不依赖传递依赖关系的情况下将其可用。它不是重复的，您还能如何告诉Maven您的模块取决于Guava？

我看不到在任何情况下都需要遵守最低限度的最佳实践的情况。

如果是，那么<version>我们指定什么方法？（<dependencyManagement>在父pom中没有+ ？）

是的，最好<dependencyManagement>在父<dependency>版本中使用，而在子版本中使用不带版本的子模块是最好的：您将确保所有模块都使用相同版本的依赖项。由于您的模块是一个整体应用程序，因此它可能会更好，因为它将避免各种问题，例如在类路径上存在相同依赖项的不同版本，从而造成混乱。

即使您的模块中使用同一父模块的模块由于某种原因需要我们依赖的版本不同，也仍然可以使用来覆盖此特定模块的版本<version>。

如果是，那么我们应该在某个模块中使用范围吗？

可能不是，具有compile范围的依赖性是大多数包装方法中最好的选择。

但是，您可能会遇到需要或倾向于这样做的情况，例如，如果所述模块需要使用运行时环境特定的版本，或者您的部署或打包模型是按需要的方式设计的。考虑到您暴露的情况，尽管大​​多数情况下都没有必要，但两者都是可能的。