java - 解决Maven依赖收敛问题

Question

我使用 maven-enforcer-plugin 来检查依赖收敛问题。典型的输出是:

[WARNING] Rule 1: org.apache.maven.plugins.enforcer.DependencyConvergence failed 
  with message:
Failed while enforcing releasability the error(s) are [
Dependency convergence error for junit:junit:3.8.1 paths to dependency are:
+-foo:bar:1.0-SNAPSHOT
  +-ca.juliusdavies:not-yet-commons-ssl:0.3.9
    +-commons-httpclient:commons-httpclient:3.0
      +-junit:junit:3.8.1
and
+-foo:bar:1.0-SNAPSHOT
  +-junit:junit:4.11
]

看到这条消息，我通常会通过排除传递依赖来“解决”它，例如

<dependency>
  <groupId>ca.juliusdavies</groupId>
  <artifactId>not-yet-commons-ssl</artifactId>
  <version>0.3.9</version>
  <exclusions>
    <!-- This artifact links to another artifact which stupidly includes 
      junit in compile scope -->
    <exclusion>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
    </exclusion>
  </exclusions>
</dependency>

我想了解这是否真的是一种修复以及以这种方式排除库所涉及的风险。在我看来:

• 只要我选择使用较新的版本，“修复”通常是安全的。这依赖于库作者保持向后兼容性。

• 通常对 Maven 构建没有影响(因为更接近的定义获胜)，但是通过排除依赖项，我告诉 Maven 我知道这个问题，从而安抚了 maven-enforcer-plugin。

我的想法是否正确，是否有其他方法可以处理此问题？我对关注一般情况的答案感兴趣 - 我意识到上面的 junit 示例有点奇怪。

Answer 1

我们都同意 JUnit 永远不应该设置为 test 以外的其他范围。一般来说，我认为除了排除不需要的依赖之外，没有其他解决方案，所以我们都同意你这样做是正确的。

一个简单的案例:

正如 Andreas Krueger 所说，版本可能存在风险(我实际上遇到过)。假设项目的依赖项如下:

+-foo:bar:1.0-SNAPSHOT
  +-group1:projectA:2.0
     +-group2:projectB:3.8.1
  +-group2:projectB:4.11

请注意，这只是对您的情况的简化。看到这个依赖树，你会排除 projectA 给出的依赖 projectB :

<dependency>
  <groupId>group1</groupId>
  <artifactId>projectA</artifactId>
  <version>2.0</version>
  <exclusions>
    <exclusion>
      <groupId>group2</groupId>
      <artifactId>projectB</artifactId>
    </exclusion>
  </exclusions>
</dependency>

使用 maven 打包项目后，剩余的依赖项将是 group2-someProjectB-4.11.jar，版本 4.11 而不是 3.8.1。一切都会好起来的，项目会运行而不会遇到任何问题。

然后，过了一会儿，假设您决定升级到项目 A 的下一个版本，即 3.0 版，它添加了新的强大功能:

<dependency>
  <groupId>group1</groupId>
  <artifactId>projectA</artifactId>
  <version>3.0</version>
  <exclusions>
    <exclusion>
      <groupId>group2</groupId>
      <artifactId>projectB</artifactId>
    </exclusion>
  </exclusions>
</dependency>

问题是你还不知道 projectA 3.0 版也已将其依赖项 projectB 升级到 5.0 版:

+-foo:bar:1.0-SNAPSHOT
  +-group1:projectA:3.0
     +-group2:projectB:5.0
  +-group2:projectB:4.11

在这种情况下，您刚才所做的排除会排除 projectB 版本 5.0。

但是，projectA 3.0 版需要对 project B 5.0 版进行改进。由于排除，使用 maven 打包项目后，剩余的依赖项将是 group2-someProjectB-4.11.jar，版本 4.11 而不是 5.0。在您使用 projectA 的任何新功能时，程序将无法正常运行。

解决方案是什么？

我在一个 Java-EE 项目中遇到了这个问题。

一个团队开发了数据库服务。他们将其打包为 projectA。每次更新服务时，他们还会更新一个文件，其中列出了所有当前依赖项和当前版本。

ProjectA 是我正在处理的 Java-EE 项目的依赖项。每次服务团队更新 ProjectA 时，我也会检查版本的更新。

事实上，排除一个依赖并没有什么坏处。但是每次你更新一个已经设置了排除的依赖时，你必须检查:

• 如果此排除仍然有意义。
• 如果您需要在自己的项目中升级排除的依赖项的版本。

我猜 maven 排除就像菜刀。它很锋利，可以毫不费力地切蔬菜，但在处理时需要小心......