Maven学习笔记七【可选的依赖项和依赖项排除】

栏目: Java · 发布时间: 5年前

内容简介:本节可选的依赖项和排除依赖项。将帮助我们了解它们是什么,合适以及如何使用。它还解释了为什么排除是基于每个依赖项而不是POM级别。可选的依赖项用于无法(无论出于何种原因)将项目分割为子模块的情况。其思想是,一些依赖项仅用于项目中的某些特性,如果不使用该特性,则不需要这些依赖项。理想情况下,这样的特性应该被分割成依赖于核心功能项目的子模块。这个新的子项目将只有非可选的依赖项,因为如果决定使用子项目的功能,将需要所有这些依赖项。然而,由于项目不能分割(同样,出于某种原因),这些依赖项声明为可选的。如果用户希望使用

本节可选的依赖项和排除依赖项。将帮助我们了解它们是什么,合适以及如何使用。它还解释了为什么排除是基于每个依赖项而不是POM级别。

可选依赖项

可选的依赖项用于无法(无论出于何种原因)将项目分割为子模块的情况。其思想是,一些依赖项仅用于项目中的某些特性,如果不使用该特性,则不需要这些依赖项。理想情况下,这样的特性应该被分割成依赖于核心功能项目的子模块。这个新的子项目将只有非可选的依赖项,因为如果决定使用子项目的功能,将需要所有这些依赖项。

然而,由于项目不能分割(同样,出于某种原因),这些依赖项声明为可选的。如果用户希望使用与可选依赖项相关的功能,他们必须在自己的项目中重新声明该可选依赖项。这不是处理这种情况的最清晰的方法,但是可选的依赖项和排除依赖项都是权宜之计。

为什么使用可选依赖项

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

如何使用可选标记

通过在依赖项声明中将 <optional> 元素设置为true,可以将依赖项声明为optional:

<project>
  ...
  <dependencies>
    <!-- declare the dependency to be set as optional -->
    <dependency>
      <groupId>sample.ProjectA</groupId>
      <artifactId>Project-A</artifactId>
      <version>1.0</version>
      <scope>compile</scope>
      <optional>true</optional> <!-- value will be true or false only -->
    </dependency>
  </dependencies>
</project>

可选依赖项如何工作

Project-A -> Project-B

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

Project-X -> Project-A

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

例子

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

依赖项排除

由于Maven是临时解决依赖项的,所以不需要的依赖项可能包含在项目的类路径中。例如,某个较旧的jar可能存在安全问题,或者与我们正在使用的 Java 版本不兼容。为了解决这个问题,Maven允许我们排除特定的依赖项。排除是在POM中的特定依赖项上设置的,并且针对特定的groupId和artifactId。在构建项目时,不会将声明了排除依赖关系的项目添加到类路径中。

如何使用依赖排除

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

<project>
  ...
  <dependencies>
    <dependency>
      <groupId>sample.ProjectA</groupId>
      <artifactId>Project-A</artifactId>
      <version>1.0</version>
      <scope>compile</scope>
      <exclusions>
        <exclusion>  <!-- declare the exclusion here -->
          <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

该图显示项目A同时依赖于项目B和项目C。项目B依赖于项目D。项目D同时依赖于项目E和F。默认情况下,项目A的类路径包括:

B, C, D, E, F

假设我们不希望将项目D及其依赖项添加到项目A的类路径中,因为存储库中缺少一些项目D的依赖项,而且也不需要项目B中依赖于项目D的功能。项目B的开发人员可以标记对项目D设置 <optional>true</optional> 依赖关系:

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

不幸的是,他们没有。最后,我们可以将其排除在您自己的项目POM中,如下所示:

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> <!-- Exclude Project-D from Project-B -->
          <artifactId>Project-D</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
  </dependencies>
</project>

如果将Project-A部署到存储库中,并且Project-X声明了对Project-A的正常依赖关系,那么Project-D仍然会被排除在类路径之外吗?

Project-X -> Project-A

答案是肯定的。Project-A已经声明它不需要Project-D来运行,所以它不会作为Project-A的传递依赖项被引入。

现在,考虑项目X依赖于项目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 <!-- Exclude this dependency -->
              -> 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> <!-- Exclude Project-E from Project-B -->
          <artifactId>Project-E</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
  </dependencies>
</project>

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

这主要是为了确保依赖关系图是可预测的,并防止继承效果排除不应该排除的依赖关系。如果使用最后一种方法,并且必须放入一个排除,那么应该完全确定是哪个依赖项引入了不需要的传递依赖项。

如果我们确实希望确保某个特定的依赖项在类路径中不出现,无论路径如何,都可以将禁用的依赖项规则( bannedDependencies )配置为在发现有问题的依赖项时构建失败。当构建失败时,您需要在执行者找到的每个路径上添加特定的排除。


以上所述就是小编给大家介绍的《Maven学习笔记七【可选的依赖项和依赖项排除】》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Linux内核完全剖析

Linux内核完全剖析

赵炯 / 机械工业出版社 / 2006-1 / 79.00元

本书对早期Linux操作系统内核全部代友文件进行了详细的剖析,旨在让读者在尽量短的时间内对Linux的工作机理获得全面而深刻的理解,为进一步学习和研究Linux系统打下坚实的基础。虽然选择的版本较低,但该内核已能够正常编译运行,并且其中已包括了Linux工作原理的精髓。书中首先以Linux源代码版本的变迁为主线,简要介绍了Lin-ux系统的发展历史,同时着重说明了各个内核版本之间的主要区别和改进方......一起来看看 《Linux内核完全剖析》 这本书的介绍吧!

HTML 压缩/解压工具
HTML 压缩/解压工具

在线压缩/解压 HTML 代码

URL 编码/解码
URL 编码/解码

URL 编码/解码

正则表达式在线测试
正则表达式在线测试

正则表达式在线测试