同一工件使用相同依赖项的不同版本

Question

我正在使用maven enforcer插件，但我发现了依赖收敛的奇怪情况：

Dependency convergence error for commons-collections:commons-collections:3.2.1 paths to dependency are:
+-ProjectA:B:0.1
+-commons-validator:commons-validator:1.6
+-commons-beanutils:commons-beanutils:1.9.2
+-commons-collections:commons-collections:3.2.1
and
+-ProjectA:B:0.1
+-commons-validator:commons-validator:1.6
+-commons-collections:commons-collections:3.2.2

这是依赖声明：

<dependency>
<groupId>commons-validator</groupId>
<artifactId>commons-validator</artifactId>
<version>1.6</version>
</dependency>

您可以看到，同一个工件使用相同依赖项的不同版本。这怎么会发生？抑制警告的唯一方法是将该依赖项的最新版本作为直接依赖项包含在pom中。

我是不是错过了什么？

Answer 1

从依赖树中可以看到，commons-validator:commons-validator:1.6直接依赖于commons-collections:commons-collections:3.2.2，但也对commons-collections:commons-collections:3.2.1有传递依赖。这没什么不寻常的。

要解决此问题，您需要选择一个版本。只需遵循khmarbaise的建议，并在POM的<dependencyManagement>部分添加一个条目。

Answer 2

最重要的是，同一个工件不会使用同一依赖项的不同版本。

+-ProjectA:B:0.1
+-commons-validator:commons-validator:1.6
+-commons-beanutils:commons-beanutils:1.9.2
+-commons-collections:commons-collections:3.2.1
and
+-ProjectA:B:0.1
+-commons-validator:commons-validator:1.6
+-commons-collections:commons-collections:3.2.2

依赖项commons-validator:commons-validator:1.6直接使用commons-collections:commons-collections:3.2.2，而传递使用commons-collections:commons-collections:3.2.1(其他依赖项的依赖项(。Maven的依赖中介将基于neares最新原则来解决这一冲突。看看这些：
[1]依赖机制
[2]依赖中介和冲突解决

maven执行器插件的dependencyConvergence规则运行良好。正如文件所说：

此规则要求依赖关系版本号收敛。如果项目有两个依赖项，A和B，都依赖于相同的工件，C，如果A依赖于不同的C的版本，然后是B所依赖的C的版本。

因为commons验证器(A(和commons beanutils(B(依赖于commons集合(C(和这些依赖项有不同的版本，所以这种行为是完全合理的。

你决定你到底想做什么

继续使用dependencyConvergence规则并解决此错误

在这种情况下，只需在<dependencyManagement>部分中定义commons-collections、commons-logging和commons-validator，并将这些依赖关系作为托管依赖关系放入项目中。

<dependencyManagement>
<dependencies>
<dependency>
<groupId>commons-validator</groupId>
<artifactId>commons-validator</artifactId>
<version>1.6</version>
</dependency>
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.2.2</version>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.2</version>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>commons-validator</groupId>
<artifactId>commons-validator</artifactId>
</dependency>
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</dependency>
</dependencies>

我认为它需要大量的过度工作，过一段时间你的项目模型将无法维护。CCD_ 12规则解决了这一问题。

使用其他规则，例如requireUpperBoundDeps

此规则旨在调查构建过程中已解析的依赖项是否低于所有传递依赖声明。例如，如果您的项目依赖于commons-collections:3.0，但commons-validator需要更新版本的commons-collections:3.2.2，则会失败

<dependencies>
<dependency>
<groupId>commons-validator</groupId>
<artifactId>commons-validator</artifactId>
<version>1.6</version>
</dependency>
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.0</version>
</dependency>
</dependencies>

忘记依赖中介中的强制者和信任

几乎在所有情况下，这都是正确的决定，因为Dependency Mediation运行良好。