Maven实战读书笔记（5）

时间 2019-11-11

标签 maven 实战读书笔记栏目 Maven 繁體版

原文原文链接

Maven编译、测试、运行会使用不一样的classpathjava

Maven再编译、测试、运行时会使用三套classpath (编译classpath、测试classpath、运行classpath)mysql

Maven有一下几种依赖范围程序员

compilespring

testsql

provide数据库

runtimeapi

systemmaven

import (Maven 2.0.9 及以上)ide

compile是指？函数

编译依赖范围，若是没有指定，就会默认使用该依赖范围，使用此依赖范围的Maven依赖，对于编译、测试、运行三种classpath都有效，典型的例子是spring-core，在编译、测试和运行的时候都须要使用该依赖

test是指？

测试依赖范围，使用此依赖范围的Maven依赖，只对于测试classpath有效，在编译主代码或者运行项目的使用时将没法使用此类依赖，典型的例子时JUnit。它只有在编译测试代码及运行测试的时候才须要

provided是指？

已提供依赖范围，使用此依赖范围的Maven依赖，对于编译和测试classpath有效，但在运行时无效。典型的例子时servlet-api，编译和测试项目的时候须要该依赖，但在运行项目的时候，因为容器已经提供，就不须要Maven重复地引入一遍

runtime是指？

运行时依赖范围，使用此依赖范围的Maven依赖，对于测试和运行classpath有效，但在编译主代码时无效。典型的例子时JDBC驱动实现，项目主代码的编译只须要JDK提供的JDBC接口，只有在执行测试或者运行项目的时候才须要实现，上述接口的具体JDBC驱动

system是指？

系统依赖范围，该依赖与三种classpath的关系，和provided依赖范围彻底一致。可是，使用system范围的依赖时必须经过systemPath元素显式地指定依赖文件的路径，因为此类以来不是经过Maven仓库解析的，并且每每与本机系统绑定，可能形成构建的不可移植，所以应该谨慎使用。systemPath元素能够引用环境变量如：

<groupId>javax.sql</groupId>

<artifactId>jdbc-stdext</artofactId>

<scope>system</scope>

</depemdency>

import是指？

导入依赖范围，该依赖范围不会对三种classpath产生实际的影响，后面会讲

上述除了import之外的各类依赖范围与三种classpath的关系

依赖范围 (Scope)	对于编译 classpath有效	对于测试 Classpath有效	对于运行时 Classpath有效	例子
Compile	Y	Y	Y	Spring-core
Test	——	Y	——	JUnit
Provided	Y	Y	——	Servlet-api
Runtime	——	Y	Y	JDBC驱动实现
System	Y	Y	——	本地的，Maven仓库以外的类库文件

在项目中手动引入依赖的问题

考虑一个基于Spring Framework的项目，若是不使用Maven，那么在项目中就须要手动下载相关依赖，因为Spring Framework又会依赖于其余开源类库，所以实际中每每会下载一个很大的如spring-framework-2.5.6-with-dependencies.zip的包，这里包含了全部Spring Framework的jar包，以及全部它依赖的其余jar包。这么作每每就引入了不少没必要要的依赖。

另外一种作法是只下载spring-framework-2.5.6.zip这样的包，这里不包含其余相关依赖，到实际使用的时候，在根据出错信息，或者相关文档，加入须要的其余依赖，很显然，这也是一件很是麻烦的事情。

Maven的传递性依赖机制能够很好地解决这一问题

若是一个项目有一个org.springframework:spring-core:2.5.6的依赖，而实际上spring-core也有它本身的依赖

咱们能够直接访问位于中央仓库的该构建的：

POM:http://repo1.maven.org/maven2/org/springframework/spring-core/2.5.6/spring-core-2.5.6.pom，该文件包含了一个commons-logging依赖:

<groupId>commons-logging</groupId>

<artifactId>commons-logging</artifactId>

</dependency>

account-mail有一个compile范围的spring-core依赖，spring-core有一个compile范围的commons-logging依赖，那么commons-logging就会成为account-email的compile范围依赖，commons-logging就是account-email的一个传递性依赖

传递性依赖机制的逻辑是？

Maven会解析各个直接依赖的POM，将那些没必要要的间接依赖，以传递性依赖的形式引入到当前的项目中

依赖范围也影响传递性依赖

依赖范围不只能够控制依赖于三种classpath的关系，还对传递性依赖产生影响

好比，account-email对于spring-core的依赖范围是compile，spring-core对于commons-loggin的依赖范围是compile，那么account-email对于commons-logging这一传递性依赖的范围也就是compile

什么是第一直接依赖，第二直接依赖？

假设A依赖于B，B依赖于C，咱们说A对于B是第一直接依赖，B对于C是第二直接依赖，A对于C是传递性依赖。第一直接依赖的范围和第二直接依赖的范围决定了传递性依赖的范围

依赖范围影响传递性依赖

	Compile	Test	Provided	Runtime
Compile	Compile	——	——	Runtime
Test	Test	——	——	Test
Provided	Provided	——	Provided	Provided
Runtime	Runtime	——	——	Runtime

最左边的一行表示第一直接依赖范围，最上面一行表示第二直接依赖范围，中间的交叉单元格则表示传递性依赖范围

仔细观察上表发现规律

1、当第二直接依赖的范围是compile的时候，传递性依赖的范围与第一直接依赖的范围一致

2、当第二直接依赖的范围是provided的时候，只传递第一直接依赖范围也为provided的依赖，且传递的范围一样为provided

3、当第二直接依赖的范围是runtime的时候，传递性依赖的范围与第一直接依赖的范围一致，但compile例外，此时传递性依赖的范围为runtime

传递性依赖机制的问题

Maven引入的传递性依赖机制，一方面大大简化和方便了依赖声明，另外一方面，大部分状况下咱们只须要关心项目的直接依赖是什么，而不用考虑这些直接依赖会引入什么传递性依赖。可是有时候，当传递性依赖形成问题的时候，咱们就须要清楚地知道该传递性依赖是从那条依赖路径引入的

如何发现传递性依赖的问题?

好比，项目A有这样的依赖关系: A -> B -> C -> X (1.0)、A->D->X(2.0)，X是A的传递性依赖，可是两条依赖路径上有两个版本的X，那么哪一个X会被Maven解析使用呢？

两个版本都被解析显然是不对的，由于那会形成依赖重复，所以必须选择一个。

Maven依赖调解的第一原则

Maven依赖调解 (Dependency Mediation) 的第一原则是：路径最近者优先，上面的例子中X(1.0)的路径长度为3，而X(2.0)的路径长度为2，所以X(2.0)会被解析使用

依赖调解第一原则不能解决全部问题

好比这样的依赖关系，A->B->Y（1.0） A->C->Y(2.0)，Y（1.0）和Y(2.0)的依赖路径长度是同样的，都为2，那么到底谁会被解析使用呢？

Maven2.0.8及以前的版本

在Maven2.0.8及以前的版本，这是不肯定的，解决不了。哦NO

Maven2.0.9版本开始

从Maven2.0.9开始，为了尽量避免构建的不肯定性，Maven定义了依赖调解的第二原则

什么是依赖调解的第二原则？

Maven的依赖调解第二原则是，第一声明者优先，在依赖路径长度相等的前提下，在POM中依赖声明的顺序决定了谁会被解析使用，顺序最靠前的那个依赖优胜，上面的例子中，若是B的依赖声明在C以前，那么Y（1.0）就会被解析使用

什么是可选依赖？
假设有这样一个依赖关系，项目A依赖于项目B，项目B依赖于项目X和Y，B对于X和Y的依赖都是可选依赖：A->B、B->X(可选)、B->Y(可选)。根据传递性依赖的定义，若是全部这三个依赖的范围都是compile，那么X、Y就是A的compile范围传递性依赖。然而，因为这X、Y是可选依赖，依赖将不会得以传递。换句话说，X、Y将不会对A有任何影响

那么，为何要使用可选依赖这一特性呢？

可能项目B实现了两个特性，其中的特性一依赖于X，特性二依赖于Y，并且这两个特性是互斥的，用户不可能同时使用两个特性。

能不能具体说明一下两个特性互斥是什么意思？

好比B是一个持久隔离工具包，它支持多种数据库，包括MySQL、PostgreSQL等，在构建这个工具包的时候，须要这两种数据库的启动程序，但在使用这个工具包的时候，只会依赖一种数据库。

项目B的依赖声明以下

<groupId>com.juvenxu.mvnbook</groupId>

<artifactId>project-b</artifactId>

<groupId>mysql</groupId>

<artifactId>mysql-connector-java</artifactId>

</dependency>

<groupId>postgresql</groupId>

<artifactId> postgresql </artifactId>

</dependency>

</dependencies>

</project>

上面的XML代码片断中，使用<optional>元素表示mysql-connector-java和postgresql这两个依赖为可选依赖，它们只会对当前项目B产生影响，当其余项目依赖于B的时候，这两个依赖不会被传递。所以，当项目A依赖于项目B的时候，若是其实际使用基于MySQL数据库，那么在项目A中就须要显式地声明mysql-connector-java这一依赖

项目a的XML代码片断

<groupId>com.juvenxu.mvnbook</groupId>

<artifactId>project-a</artifactId>

<groupId> com.juvenxu.mvnbook </groupId>

<artifactId> project-b </artifactId>

</dependency>

<groupId>mysql</groupId>

<artifactId>mysql-connector-java</artifactId>

</dependency>

</dependencies>

</project>

最后强调几点

1、在理想的状况下，是不该该使用可选依赖的

2、使用可选依赖的缘由是某一个项目实现了多个特性，可是违背了单一职责原则

3、规划Maven项目的时候也应该遵循这个原则

更好的作法是？

1、为MySQL和PostgreSQL分别建立一个Maven项目，基于一样的groupId分配不一样的artifactId

2、如com.juvenxu.mvnbook:project-b-mysql和com.juvenxu.mvnbook:project-b-postgresql

3、在各自的POM中声明对应的JDBC驱动依赖，并且不使用可选依赖，用户根据须要选择使用project-b-mysql或者project-b-postgresql，因为传递性依赖的做用，就不用再声明JDBC驱动依赖了

最佳实践

传递性依赖带来的两个问题

1、当项目有一个第三方依赖，而这个第三方依赖因为某些缘由依赖了另一个类库的SNAPSHOT版本，那么这个SNAPSHOT就会成为当前项目的传递性依赖，而SNAPSHOT的不稳定性会直接影响到当前的项目。这时就须要排除掉该SNAPSHOT，而且在当前项目中声明该类库的某个正式发布的版本

2、你可能想要替换某个传递性依赖，好比Sun JTA API，Hibernate依赖于这个JAR，可是因为版权的因素，该类库不在中央仓库中，而Apache Gernimo项目有一个对应的实现。这时你就能够排除Sun JTA API，再声明Geronimo的JTA API实现

关于排除掉某个传递性依赖如何操做？

<groupId>com.juvenxu.mvnbook</groupId>

<artifactId>project-a</artifactId>

<groupId> com.juvenxu.mvnbook </groupId>

<artifactId> project-b </artifactId>

<groupId> com.juvenxu.mvnbook </groupId>

<artifactId> project-c </artifactId>

</exclustion>

</exclustions>

</dependency>

<groupId> com.juvenxu.mvnbook </groupId>

<artifactId> project-c </artifactId>

</dependency>

</dependencies>

</project>

上面的代码，项目A依赖于项目B，但因为一些缘由，不想引入传递性依赖C，而是本身显式地声明对于项目C 1.1.0 版本的依赖。

代码中使用exclusions元素声明排除依赖，exclusions能够包含一个或者多个exclusion子元素，所以能够排除一个或者多个传递性依赖

须要注意的是，groupId和artifactId就能惟必定位依赖图中的某个依赖

若是要升级依赖的版本

考虑这样一种场景，有不少关于Spring Framework的依赖

它们分别是:

org.springframework:spring-core:2.5.6

org.springframework:spring-beans:2.5.6

org.springframework:spring-context:2.5.6

org.springframework:spring-context-support:2.5.6

它们是来自同一项目的不一样模块，所以，全部这些依赖的版本都是相同的，并且能够预见

若是未来须要升级Spring Framework，这些依赖的版本会一块儿升级，这是个问题，全部的version都得改一遍，这种状况在Java中似曾相识

若是说技术是想通的话，那么看一下为何java会喜欢使用常量？

考虑

public double c(double r) {

return 2 * 3.14 * r

}
public double s(double r) {

return 3.14 * r * r

}
上面两个函数计算圆的周长和面积，稍微有经验的程序员一眼就会看出一个问题，使用字面量(3.14)显然不合适，应该使用定义一个常量并在方法中使用

public final double PI = 3.14;

public double c(double r) {

return 2 * PI * r

}
public double s(double r) {

return PI * r * r

}

使用常量不只让代码变得更加简洁，更重要的是能够避免重复，在须要更改PI的值的时候，只须要修改移除，下降了错误发生的几率。

同理应用与Maven

对于account-mail中的Spring Framework来讲，也应该在一个惟一的地方定义版本，而且在dependency声明中引用这一版本，这样，在升级Spring Framework的时候就只须要修改一处

<groupId>com.juvenxu.mvnbook</groupId>

<artifactId>account-email</artifactId>

<name>Account Email</name>

<springframework.version>2.5.6</springframework.version>

</projecties>

<groupId>org.springframwork</groupId>

<artifactId>spring-core</artifactId>

<version>${ springframework.version }<version>

</dependency>

<groupId>org.springframwork</groupId>

<artifactId>spring-beans</artifactId>

<version>${ springframework.version }<version>

</dependency>

<groupId>org.springframwork</groupId>

<artifactId>spring-context</artifactId>

<version>${ springframework.version }<version>

</dependency>

<groupId>org.springframwork</groupId>

<artifactId>spring-context-support</artifactId>

<version>${ springframework.version }<version>

</dependency>

</dependencies>

</project>

解释上面的代码

这里简单用到了Maven属性，首先使用properties元素定义Maven属性，该例中定义了一个springframework.version子元素，其值为2.5.6

有了这个属性定义以后，Maven运行的时候会将POM中的全部的${springframework.version}替换成实际值2.5.6，也就是说，可使用美圆符号和大括号环绕的方式引用Maven属性。而后，将全部Spring Framework依赖的版本值用这一属性应用表示。这和在Java中用常量PI替换3.14是一样的道理，不一样的只是语法

什么是Maven的属性？

优化依赖

在软件开发过程当中，程序员会经过重构等方式不断地优化本身得代码，使其变得更简洁、更灵活。同理，程序员也应该可以对Maven项目的依赖了然于胸，并对其进行优化，如去除多余的依赖，显式地声明某些必要得依赖

什么是已解析依赖(Resolved Dependency)？

Maven会自动解析全部项目的直接依赖和传递依赖，而且根据规则正确判断每一个依赖的范围，对于一些依赖冲突，也能进行调节，以确保任何一个构件只有惟一的版本在依赖中存在，在这些工做以后最后获得的那些依赖被称为一解析依赖

查看当前项目的已解析依赖的命令有
mvn dependency:list

mvn dependency:tree

mvn dependency:analyze

关于mvn dependency:analyze命令须要注意的是?

mvn dependency:analyze工具能够帮助分析当前项目的依赖

1、Used undeclared dependencies 指项目中使用到的，但没有显式声明的依赖，这种依赖是经过直接依赖传递进来的，当升级直接依赖的时候，相关的传递性依赖的版本也可能发生变化，这种变化不易察觉，可是有可能致使当前项目出错。例如因为接口的改变，当前项目中的相关代码没法编译，这种隐藏的、潜在的威胁一旦出现，就每每须要耗费大量的时间来查明真相，所以，显式声明任何项目中直接用到的依赖

2、Unused declared dependencies，意指项目中未使用的，但显式声明的依赖，对于这类依赖不该该简单地直接删除其声明，而应该仔细分析，因为dependency:analyze只会分析编译主代码和测试代码须要用到的依赖，一些执行测试和运行时须要的依赖它发现不了。