假设我们正在研究抵押子模块，并且直接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？
我们直接在模块代码中使用Google Guava类，但是番石榴的依赖关系是在同一父项下的其他子模块中定义的，我们只能通过对“投资”模块的传递依赖来访问Guava类[...]我们是否仍应在抵押pom.xml中向Guava添加一个？
是的，您应该在模块中声明Google Guava依赖项，并且不要期望它可以作为传递依赖项使用。即使它与当前版本兼容，在更高版本的直接依赖项中也可能不再如此。
如果您的代码依赖于模块，则您的代码应仅直接依赖于此模块的类，而不应依赖于此模块的传递依赖。如您所述，不能保证投资模块将来将继续依赖Guava。您需要在父级的pom.xml或模块本身中指定此依赖关系，以确保在不依赖传递依赖关系的情况下将其可用。它不是重复的，您还能如何告诉Maven您的模块取决于Guava？
我看不到在任何情况下都需要遵守最低限度的最佳实践的情况。
如果是，那么
<version>我们指定什么方法？（<dependencyManagement>在父pom中没有+ ？）
是的，最好<dependencyManagement>在父<dependency>版本中使用，而在子版本中使用不带版本的子模块是最好的：您将确保所有模块都使用相同版本的依赖。由于您的模块是一个整体应用程序，因此它可能会更好，因为它将避免各种问题，例如在类路径上存在相同依赖项的不同版本，从而造成混乱。
即使出于某种原因，您的使用同一父级的模块之一需要我们依赖关系的不同版本，仍然可以使用来覆盖此特定模块的版本<version>。
如果是，那么我们应该在某个模块中使用范围吗？
可能不是，具有compile范围的依赖性是大多数包装方法中最好的选择。
但是，在某些情况下，您可能需要或希望这样做，例如，如果所述模块需要使用运行时环境特定的版本，或者您的部署或打包模型是按要求的方式设计的。考虑到您暴露的情况，尽管大多数情况下都没有必要，但两者都是可能的。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句