【问题标题】:Why is there the option to exclude a dependency of a dependency in pom.xml / maven?为什么有排除 pom.xml / maven 中依赖项的依赖项的选项?
【发布时间】:2019-04-16 03:23:43
【问题描述】:

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

  <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

【问题讨论】:

    标签: java apache maven build pom.xml


    【解决方案1】:

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

    【讨论】:

      【解决方案2】:

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

      我们的一个依赖项(它相当大,但我们只需要几个独立的方法)依赖于Rhino,但我们不会去靠近代码中涉及 ​​Rhino 的部分。

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

      结果是,包括 Rhino 的传递依赖破坏了以前工作的功能。 YUI Compressor 引发了运行时异常,因为该方法的签名与预期不同。

      解决方案是明确排除 Rhino。


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

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

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

      【讨论】:

        猜你喜欢
        • 2012-02-25
        • 2013-11-06
        • 1970-01-01
        • 2014-02-19
        • 1970-01-01
        • 2021-11-23
        • 1970-01-01
        • 2012-08-16
        • 2015-04-13
        相关资源
        最近更新 更多