Maven实战07_依赖

Posted 2020-09-27 高山仰止

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：可选依赖

    假设有这样一种依赖关系，项目A依赖于项目B，项目B依赖于项目X和项目Y，B对于X和Y的依赖都是可选依赖（optional为true）：A -> B,B -> X（可选）,B -> Y（可选）。根据传递性依赖的定义，如果所有这三个依赖的范围都是compile，那么X,Y就是A的compile范围传递性依赖。然而，由于这里X,Y是可选依赖，依赖就不会传递，也就是说，X，Y将不会对A有任何影响 。

    为什么要使用可选依赖这一特性呢？可能B项目实现了两个特性，其中的一个特性一依赖于X，特性二依赖于Y，而且这两个特性是相互排斥的，用户不可能同时使用两个特性，比如B是一个持久层隔离工具包，它支持多种数据库，包括mysql，PostgreSQL等，在构建这个工具包时，需要这两种数据库的驱动程序，但在使用这个工具包的时候，只会依赖一种数据库。

    在理想情况下，是不应该使用可选依赖的，因为使用了可选依赖的原因是某一个项目实现了多个特性，在面向对象设计中，有个单一职责性原则，意指一个类应该只有一个职责，而不是糅合太多的功能。这个原则在规划Maven的时候同样适用。

7：最佳实践

• 排除依赖

  之所以要排除依赖的原因有以下几点：

1. 依赖不稳定，需要正式版本，多为引用第三方依赖中包含这个不稳定依赖导致
2. 由于版权，依赖不再中央仓库，需要排除改依赖

上述图排除依赖的代码清单

<project xmlns="http://maven.apache.org/POM/4.0.0" 

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> 

<modelVersion>4.0.0</modelVersion> 


<groupId>xx.xxx.xx</groupId> 

<artifactId>A</artifactId> 

<version>1.0-SNAPSHOT</version> 

<dependency> 

<groupId>xx.xxx.xx</groupId> 

<artifactId>B</artifactId> 

<version>1.0</version> 

<!-- 排除C的不稳定依赖 --> 

<exclusions> 

<exclusion> 

<groupId>xx.xx.xx</groupId> 

<artifactId>C</artifactId> 

</exclusion> 

</exclusions> 

</dependency> 

<!-- 引入C的稳定依赖 --> 

<dependency> 

<groupId>xx.xx.xx</groupId> 

<artifactId>C</artifactId> 

<version>1.0</version> 

</dependency> 

</project>

代码清单说明

     上述代码中，项目A依赖于项目B，但是由于一些原因，不想引入项目B中的依赖C，而是自己显示的声明对于项目C稳定版本1.0的依赖。所以在项目B中使用exclusions对依赖进行排除，由英语语法的单复数可知，在exclusions中可包含多个exclusion，即可排除多个依赖。需要注意的是，声明exclusion的时候只需要groupId和artifactId，而不需要version元素，这是因为只需要groupId和artifactId就能唯一定位依赖图中的某个依赖。也就是说，在Maven依赖中，不可能出现groupId和artifactId相同但是version不同的两个依赖。

• 归类依赖

  之所以使用归类依赖，是为了保持版本的一致性，排除出错，例如我们通常在整合Spring Framework的时候，有很多都是相同版本的，对此，Maven也提供了归类依赖的方式简单管理版本，这样做的好处就是，将来在升级版本的时候，只需要改这个归类，不需要改所有的依赖版本了。这个就和Java中的常量是一个意思，在Maven中通过EL表达式替换。

  归类依赖的语法：

  <properties>
  <springframeword.version>4.1.5</springframeword.version>
  </properties>

  <!— 使用 -->

  <dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-core</artifactId>
  <version>${springframeword.version}</version>
  </dependency>

   

• 优化依赖

  优化依赖是指：对项目的依赖进行优化，去除多余的依赖，显式的声明某些必要的依赖

  使用mvn dependency:list查看当前项目的已解析依赖，依赖范围

  使用mvn dependency:tree查看当前的依赖树，可以清晰的看到依赖的引入路径

  使用mvn dependency:anapyze分析依赖，只会分析编译主代码和测试代码需要用到的依赖，一些执行测试和运行时需要的依赖就发现不了。