首页 > 代码库 > Maven实战07_依赖

Maven实战07_依赖

2024-10-19 21:35:39   202人阅读

1：依赖声明

<project>
  ...
  <dependencies>
    <dependency>
      <groupId>...</groupId>
      <artifactId>...</artifactId>
      <version>...</version>
      <type>...</type>
      <scope>...</scope>
      <optional>...</optional>
      <exclusions>
        <exclusion>
          ...·
        </exclusion> 
        ...
     </exclusions>
    </dependency>
  </dependencies>
  ...
</project>

解释说明：

  • 根元素prject下的dependencies可以包含一个或所个dependency元素，以声明一个或多个项目依赖
  • groupId、artifactId、version：依赖的基本坐标，每一个依赖必须具备的属性，Maven只有根据这些坐标才能找到并下载依赖
  • type：依赖的类型，对应于项目坐标定义的packaging。大部分情况下，不必声明，默认为jar
  • scope：依赖的范围，见下面2：依赖范围
  • optional：标记依赖是否可选，见下面4：依赖可选
  • exclusion：用来排除传递性依赖，见下面3：传递性依赖

2：依赖范围（用于确认是否可导入依赖包）

Maven在编译项目主代码的时候需要使用一套classpath。例如，邮件模块中的javax.mai依赖会出现

Maven在编译和执行测试的时候会使用另一套classpath。例如,Juni依赖t只会出现在测试classpath下，javax.mail也会出现

Maven在运行实际项目的时候，又会使用一套classspath。例如，javax.mail需要出现，junit则不需要出现。

依赖范围就是用来控制依赖与这三种classpath的（编译classpath、测试classpath、运行classpath）的关系，Maven有以下几种依赖范围：

  • compile：编译依赖范围。如果没有指定，默认的依赖范围。此依赖范围的Maven依赖，对于编译、测试、运行三种classpath都有效。
  • test：测试依赖范围，此依赖范围的Maven依赖，只对于测试的classpath有效，在项目编译主代码或者运行项目的使用时将无法使用此类依赖。
  • provided：已提供依赖范围，此依赖范围的Maven依赖，对于编译和测试classpath有效，但在运行时无效，例如SpringBoot生成war包，其中的tomcat依赖就要是provided依赖范围，在开发中，就要改成compile依赖
  • runtime：运行时依赖范围，此依赖范围的Maven依赖，对于测试和运行有效，但在编译主代码时无效，典型的例子就是JDBC驱动实现，项目主代码的编译只需要JDK提供的JDBC接口，只有在执行测试或者运行项目的时候才需要实现上述接口。
  • system：系统依赖范围，该依赖与三种classpath的关系，和provided依赖范围完全一致。但是使用system范围的依赖必须通过systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过Maven仓库解析的，而且往往与本机系统绑定，可能造成构建的不可移植，因此要谨慎使用。systemPath可以引用环境变量，如：
<dependency>
    <groupId>javax.sql</groupId>
    <artifactId>jdbc-stdext</artifactId>
    <version>2.0</version>
    <scope>system</scope>
    <systemPath>${java.home}/lib/rt.jar</systemPath>
</dependency>
  • import（Maven2.0.9及以上）：导入依赖范围，该依赖范围不会对三种classpath产生实际的影响。

上述出import以外的各种依赖范围与三种classpath的关系表:

技术分享

3：传递性依赖

一个基于SpringFramework的项目，如果不使用Maven，就要手动的去添加依赖包，通常是去官网下载，但是里面的依赖很多，会有不必要的依赖存在。另一种做法就是下载必要依赖包，但是这个包中不包含其他相关依赖，到实际使用的时候，根据报错引入相关依赖，这种做法是很麻烦的。

Maven的传递性依赖机制可以解决这个问题，例如：有一个spring-core的依赖，而在spring-core中也存在自己的依赖，包含了一个commons-logging依赖，见代码清单：

<dependency>
    <groupId>commons-logging</groupId>
    <artifactId>commons-logging</artifactId>
    <version>1.1.1</version>
    <scope>compile</scope>
</dependency>

该依赖的依赖范围是compile。而spring-core的依赖范围也是cmpile，因此就会出现传递性依赖，使得项目也同时依赖commons-logging，如图所示

技术分享

4：传递性依赖和依赖范围

针对上图的传递性依赖做一些解释

Maven project 依赖于 spring-core ： 第一直接依赖

spring-core 依赖于 commons-logging ：第二直接依赖

Maven project 对于 commons-logging：传递依赖

技术分享

5：依赖调解

并不是所有的传递性依赖都能正常工作，当传递性依赖造成问题的时候，我们就需要清楚的知道该传递性依赖是从哪条依赖路径引入的。

例如：

  • 第一原则：路径最近者优先：

      在项目A中存在这样的依赖。A –> B –> C –>X(1.0)、A –> D –> X(2.0)，X是A的传递性依赖，但是这两条依赖路径上有两个版本的X，那么哪个X会被Maven解析使用呢？在Maven中采用路径最近者优先策略，因此，X(2.0)会被解析使用

  • 第二原则：第一声明者优先

      在针对第一原则下路劲相同，版本不一致的缺陷下提出了第二原则，在项目A中存在这样的依赖关系。A –> B –> Y(1.0)、A –> C – > Y(1.0)，Y的依赖路径都是2，从Maven2.0.9开始，为了避免构建对的不确定性，Maven使用了该原则，在依赖路径相等的情况下，在POM中依赖声明的顺序决定了谁会被解析使用，顺序最靠前的那个依赖优胜，如果B的依赖声明在C之前，那么Y(1.0)就会被解析使用。

6：可选依赖

Maven实战07_依赖


联系
我们