Maven中option与exclusion的区别

逃离我推掉我的手 2022-02-05 01:55 215阅读 0赞

# Optional Dependencies #

当无法（无论出于何种原因）将项目拆分为子模块时，将使用option依赖项。 我们的想法是，某些依赖项仅用于项目中的某些功能，如果不使用该功能则不需要。 理想情况下，这样的功能将被拆分为依赖于核心功能项目的子模块。 这个新的子项目只有非可选的依赖项，因为如果你决定使用子项目的功能，你需要它们。  
  
但是，由于项目无法拆分（无论出于何种原因），因此这些依赖项被声明为可选项。 如果用户想要使用与可选依赖项相关的功能，则必须在自己的项目中重新声明该可选依赖项。 这不是处理这种情况的最清晰的方法，但可选的依赖项和依赖项排除都是间隙解决方案。

**为什么使用可选的依赖?**

可选的依赖项可节省空间和内存。 它们可以防止有问题的jar违反许可协议或导致类路径问题被捆绑到WAR，EAR，jar等中。

**怎样使用可选的依赖?**

通过在其依赖项声明中将<optional>元素设置为true，可以将依赖项声明为可选：

<project>
          ...
          <dependencies>
            
            <dependency>
              <groupId>sample.ProjectA</groupId>
              <artifactId>Project-A</artifactId>
              <version>1.0</version>
              <scope>compile</scope>
              <optional>true</optional> 
            </dependency>
          </dependencies>
        </project>

**可选依赖项如何使用？**

1.Project-A -> Project-B

上图表示Project-A依赖于Project-B。 当A在其POM中将B声明为可选依赖项时，此关系保持不变。 它就像一个普通的构建，Project-B将被添加到Project-A的类路径中。

1.Project-X -> Project-A

当另一个项目（Project-X）将Project-A声明为其POM中的依赖项时，依赖项的可选性质将生效。 Project-B未包含在Project-X的类路径中。 您需要直接在Project X的POM中声明它，以便B包含在X的类路径中。

**举例**

假设有一个名为X2的项目具有与Hibernate类似的功能。 它支持许多数据库，如MySQL，PostgreSQL和几个版本的Oracle。 每个受支持的数据库都需要对驱动程序jar的额外依赖。 编译时需要所有这些依赖项来构建X2。 但是，您的项目仅使用一个特定数据库，而不需要其他驱动程序。 X2可以将这些依赖项声明为可选，因此当您的项目将X2声明为其POM中的直接依赖项时，X2支持的所有驱动程序都不会自动包含在项目的类路径中。 您的项目必须包含对其使用的一个数据库的特定驱动程序的显式依赖。

**怎样使用exclusions?**

在<dependency>元素中添加<exclusions>元素，其中包含有问题的jar。

<project>
          ...
          <dependencies>
            <dependency>
              <groupId>sample.ProjectA</groupId>
              <artifactId>Project-A</artifactId>
              <version>1.0</version>
              <scope>compile</scope>
              <exclusions>
                <exclusion>  
                  <groupId>sample.ProjectB</groupId>
                  <artifactId>Project-B</artifactId>
                </exclusion>
              </exclusions> 
            </dependency>
          </dependencies>
        </project>

**依赖项排除的工作原理以及何时使用它（作为最后的手段！）**

Project-A
           -> Project-B
                -> Project-D <! -- This dependency should be excluded -->
                      -> Project-E
                      -> Project-F
           -> Project C

该图显示Project-A依赖于Project-B和C.Project-B依赖于Project-D。 Project-D依赖于Project-E和F.默认情况下，Project A的类路径将包括：

B, C, D, E, F

假设您不希望将项目D及其依赖项添加到项目A的类路径中，因为存储库中缺少某些Project-D的依赖项，并且您不需要依赖于Project-B的Project-D中的某些功能。 Project-B的开发人员可以标记对Project-D <optional> true </ optional>的依赖：

<dependency>
          <groupId>sample.ProjectD</groupId>
          <artifactId>ProjectD</artifactId>
          <version>1.0-SNAPSHOT</version>
          <optional>true</optional>
        </dependency>

不幸的是，他们没有。 作为最后的手段，您可以在自己的POM中将其排除在Project-A之外：

<project>
          <modelVersion>4.0.0</modelVersion>
          <groupId>sample.ProjectA</groupId>
          <artifactId>Project-A</artifactId>
          <version>1.0-SNAPSHOT</version>
          <packaging>jar</packaging>
          ...
          <dependencies>
            <dependency>
              <groupId>sample.ProjectB</groupId>
              <artifactId>Project-B</artifactId>
              <version>1.0-SNAPSHOT</version>
              <exclusions>
                <exclusion>
                  <groupId>sample.ProjectD</groupId> 
                  <artifactId>Project-D</artifactId>
                </exclusion>
              </exclusions>
            </dependency>
          </dependencies>
        </project>

如果将Project-A部署到存储库（repository），并且Project-X声明对Project-A的正常依赖性，Project-D是否仍会从类路径中排除？

Project-X -> Project-A

答案是肯定的。 Project-A已声明它不需要Project-D运行，因此它不会作为Project-A的传递依赖项引入。

现在，考虑Project-X依赖于Project-Y，如下图所示：

Project-X -> Project-Y
                       -> Project-B
                            -> Project-D
                               ...

Project-Y也依赖于Project-B，它确实需要Project-D支持的功能。 因此，它不会在其依赖项列表中对Project-D进行排除。 它还可以提供一个额外的存储库，从中可以解析Project-E。 在这种情况下，重要的是不要在全局范围内排除Project-D，因为它是Project-Y的合法依赖项。

另一种情况是，假设您不需要的依赖项是Project-E而不是Project-D。 你怎么排除它？ 见下图：

Project-A
           -> Project-B
                -> Project-D 
                      -> Project-E 
                      -> Project-F
           -> Project C

排除对于声明它们的点下面的整个依赖关系图有效。 如果要排除Project-E而不是Project-D，只需将排除更改为指向Project-E，但不要将排除项向下移动到Project-D。 你不能改变Project-D的POM。 如果可以，您可以使用可选的依赖项而不是排除项，或者将Project-D拆分为多个子项目，每个子项目只包含正常的依赖项。

<project>
          <modelVersion>4.0.0</modelVersion>
          <groupId>sample.ProjectA</groupId>
          <artifactId>Project-A</artifactId>
          <version>1.0-SNAPSHOT</version>
          <packaging>jar</packaging>
          ...
          <dependencies>
            <dependency>
              <groupId>sample.ProjectB</groupId>
              <artifactId>Project-B</artifactId>
              <version>1.0-SNAPSHOT</version>
              <exclusions>
                <exclusion>
                  <groupId>sample.ProjectE</groupId> 
                  <artifactId>Project-E</artifactId>
                </exclusion>
              </exclusions>
            </dependency>
          </dependencies>
        </project>

为什么排除是基于每个依赖性而不是POM级别?

这主要是为了确保依赖图是可预测的，并通过排除不应排除的依赖项来保持继承效果。 如果你采用最后的方法并且必须进行排除，那么你应该绝对确定你的哪些依赖项带来了不必要的传递依赖。

如果您确实希望确保特定依赖项无法在类路径中出现，而不考虑路径，则可以配置\[禁止依赖关系规则\]（https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html） 如果找到有问题的依赖项，则使构建失败。 当构建失败时，您需要在强制执行程序找到的每个路径上添加特定的排除项。