为什么在pom.xml / maven中可以选择排除依赖项的依赖项?

时间:2018-11-13 10:09:02

标签: java apache maven build pom.xml

我一直在阅读Introduction to POM,但不理解以下内容。在pom.xml中,您可以配置依赖项,假设我们配置了依赖项maven-embedder。然后,您可以排除依赖项的依赖项,假设我们要从maven-core依赖项中排除maven-embedder。您想在什么情况下这样做?如果没有所有依赖项,这会导致您的依赖项停止工作吗?我显然在这里缺少拼图块:)

  <dependencies>
    <dependency>
      <groupId>org.apache.maven</groupId>
      <artifactId>maven-embedder</artifactId>
      <version>2.0</version>
      <exclusions>
        <exclusion>
          <groupId>org.apache.maven</groupId>
          <artifactId>maven-core</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
    ...
  </dependencies>

示例:https://maven.apache.org/pom.html#Exclusions

2 个答案:

答案 0 :(得分:2)

这里的技巧是,您可能想使用传递依赖的另一版本,而不是默认版本。换句话说,您可以替换甚至禁用某些默认行为。

答案 1 :(得分:2)

也许一个例子会有所帮助。我们最近有一个用例。

我们的依赖项(相当大,但是我们只需要几个隔离的方法)就依赖于Rhino,但是我们不会去接近它的犀牛接触部分的任何地方。码。

在我们的模块中,我们包含了YUI Compressor。无论出于何种原因,这两个库都具有完全相同的完全合格的类名,但方法签名稍有不同。

结果是,包括Rhino的传递依赖关系在内,破坏了以前有效的功能。 YUI Compressor抛出了运行时异常,因为该方法的签名不同于预期。

解决方案是明确排除Rhino。


通常,您不必排除依赖项。通常是由于模块设计不当造成的。

例如,如果模块变得太大,那么大多数用户可能只需要一部分类或方法,因此并非严格要求它们的所有依赖关系。在这种情况下,库设计人员可能应该将模块分解为一组较小的模块。

在两个不同的库中具有相同的完全限定的类名似乎也是一个糟糕的设计决定。