如果它们来自父级的其他子模块，我是否应该依赖Maven中的传递依赖项? [英] Should I rely on transitive dependencies in Maven if they come from other sub-module of my parent?

问题描述

假设我们正在研究抵押子模块，并且我们直接在模块代码中使用Google Guava类，但是guava的依赖关系在下面的其他子模块中定义同一父级，并且我们只能通过对投资"模块的传递依赖来访问Guava类:

Suppose we are working on mortgage sub-module, and we are directly using the Google Guava classes in module code, but the dependcy for the guava is defined in other sub-module under the same parent and we have access to Guava classes only by transitive dependency on "investment" module:

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

我们还应该在抵押pom.xml 中将<dependency>放入番石榴吗?

Should we still put a <dependency> to Guava in the mortgage pom.xml?

缺点看起来像我们pom.xml中的重复项，优点是:如果有人开发投资"将丢弃番石榴，那么它不会阻止我们的抵押子模块成功构建.

The cons looks like duplication in our pom.xml, the pros are: if someone developing "investment" will drop guava, then it will not stop our mortgage sub-module from being successfuly build.

如果是，那么我们指定什么<version>方式? (没有+父pom中的<dependencyManagement>吗?)

If yes, then what <version> shoudle we specify? (none + <dependencyManagement> in parent pom?)

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

If yes, should we use a <provided> scope in some module then?

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

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

Maybe this structure was not the best example, imagine:

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

Investment在使用@Component时是否仍应显式声明Spring，如果使用Guava的LoadedCache，则应声明Guava?

Should still Investment explicitly declare Spring when it use @Component, and declare Guava if it uses Guava's LoadedCache?

推荐答案

我们直接在模块代码中使用Google Guava类，但是 番石榴的依赖关系在同一子模块的其他子模块中定义 父级，并且我们只能通过传递来访问番石榴类 依赖于投资"模块[...]我们是否仍应在抵押pom.xml中为Guava添加一个符号?

we are directly using the Google Guava classes in module code, but the dependcy for the guava is defined in other sub-module under the same parent and we have access to Guava classes only by transitive dependency on "investment" module [...] Should we still put a to Guava in the mortgage pom.xml?

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

Yes, you should declare Google Guava dependency in your module and not expect it to be available as transitive-dependency. Even if it works with the current version, it may not be the case anymore in later versions of direct dependencies.

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

If your code depends on a module, your code should depends only directly on classes of this module, not a transitive-dependency of this module. As you mentioned, there is no guarantee that the investment module will continue to depend on Guava in the future. You need to specify this dependency either in the parent's pom.xml or in the module itself to ensure it will be available without relying on transitive dependencies. It's not duplication as such, how else can you tell Maven your module depends on Guava?

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

I do not see any situation in which minimal best practices are respected where you would need to do otherwise.

如果是，那么我们指定什么<version>方式? (没有+父pom中的<dependencyManagement>吗?)

If yes, then what <version> shoudle we specify? (none + <dependencyManagement> in parent pom?)

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

Yes, using <dependencyManagement> in parent and using a <dependency> in your child module without version is best: you will make sure all your modules uses the same version of your dependency. As your modules are an application as a whole, it is probably better as it will avoid various issues such as having different versions of the same dependency being present on the classpath causing havoc.

即使出于某种原因，使用同一父级的模块之一需要我们依赖的版本不同，仍然可以使用<version>覆盖此特定模块的版本.

Even if for some reason one of your module using the same parent requires a different version of our dependency, it will still be possible to override the version for this specific module using <version>.

如果是，那我们应该在某个模块中使用作用域吗?

If yes, should we use a scope in some module then?

可能不是，对于大多数包装方法来说，具有compile范围的依赖性是最好的选择.

Probably not, having the dependency with a compile scope is the best wat to go with most packaging methods.

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

However you may have situations where you need or prefer to do this, for example if said modules requires to use a runtime environment specific version, or if your deployment or packaging model is designed in a way that demands it. Given the situation you expose, both are possible, though most of the time it should not be necessary.

这篇关于如果它们来自父级的其他子模块，我是否应该依赖Maven中的传递依赖项?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！