Maven实战07_依赖
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:最佳实践
- 排除依赖
之所以要排除依赖的原因有以下几点:
- 依赖不稳定,需要正式版本,多为引用第三方依赖中包含这个不稳定依赖导致
- 由于版权,依赖不再中央仓库,需要排除改依赖
上述图排除依赖的代码清单
<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分析依赖,只会分析编译主代码和测试代码需要用到的依赖,一些执行测试和运行时需要的依赖就发现不了。