【Maven实战】05 依赖

---

---

1.依赖的配置

一个依赖声明可以包含如下的一些元素：

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

根元素project下的dependencies可以包含一个或者多个dependency元素，以声明一个或者多个项目依赖。每个依赖可以包含的元素有：

groupId、artifactId和version：依赖的基本坐标，对于任何一个依赖来说，基本坐标是最重要的，Maven根据坐标才能找到需要的依赖。

type：依赖的类型，对应于项目坐标定义的packaging。大部分情况下，该元素不必声明，其默认值为jar。

scope：依赖的范围。

optional：标记依赖是否可选。

exclusions：用来排除传递性依赖。

大部分依赖声明只包含基本坐标，然而在一些特殊情况下，其他元素至关重要。

2.依赖范围

首先，Maven在编译项目主代码的时候需要使用一套classpath。其次，Maven在编译和执行测试的时候会使用另外一套classpath。最后，实际运行Maven项目的时候，又会使用一套classpath。

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

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元素可以引用环境变量，如：

<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：导入依赖范围。该依赖范围不会对三种classpath产生实际的影响。

上述除import以外的各种依赖范围与三种classpath的关系如下所示：

3 .传递性依赖

3.1 何为传递性依赖

考虑一个基于Spring Framework的项目，如果不使用Maven，那么在项目中就需要手动下载相关依赖。由于SpringFramework又会依赖于其他开源类库，因此实际中往往会下载一个很大的如spring-framework-2.5.6-with-dependencies.zip的包，这里包含了所有Spring Framework的jar包，以及所有它依赖的其他jar包。这么做往往就引入了很多不必要的依赖。另一种做法是只下载spring-framework-2.5.6.zip这样一个包，这里不包含其他相关依赖，到实际使用的时候，再根据出错信息，或者查询相关文档，加入需要的其他依赖。很显然，这也是一件非常麻烦的事情。

Maven的传递性依赖机制可以很好地解决这一问题。假设项目A有一个org.springframe-work: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依赖，如下所示：

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

该依赖没有声明依赖范围，那么其依赖范围就是默认的compile。

如果项目A有一个compile范围的spring-core依赖，spring-core有一个compile范围的commons-logging依赖，那么commons-logging就会成为项目A的compile范围依赖，commons-logging是项目A的一个传递性依赖。

有了传递性依赖机制，在使用Spring Framework的时候就不用去考虑它依赖了什么，也不用担心引入多余的依赖。Maven会解析各个直接依赖的POM，将那些必要的间接依赖，以传递性依赖的形式引入到当前的项目中。

3.2 传递性依赖和依赖范围

依赖范围不仅可以控制依赖与三种classpath的关系，还对传递性依赖产生影响。

假设A依赖于B，B依赖于C，我们说A对于B是第一直接依赖，B对于C是第二直接依赖，A对于C是传递性依赖。第一直接依赖的范围和第二直接依赖的范围决定了传递性依赖的范围，如下所示，最左边一列表示第一直接依赖范围，最上面一行表示第二直接依赖范围，中间的交叉单元格则表示传递性依赖范围。

4.依赖调节

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

例如，项目A有这样的依赖关系：A->B->C->X（1.0）、A->D->X（2.0），X是A的传递性依赖，但是两条依赖路径上有两个版本的X，那么哪个X会被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。那么到底谁会被解析使用呢？为了尽可能避免构建的不确定性，Maven定义了依赖调解的第二原则：第一声明者优先。在依赖路径长度相等的前提下，在POM中依赖声明的顺序决定了谁会被解析使用，顺序最靠前的那个依赖优胜。该例中，如果B的依赖声明在C之前，那么Y（1.0）就会被解析使用。

5.可选依赖

假设有这样一个依赖关系，项目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等，在构建这个工具包的时候，需要这两种数据库的驱动程序，但在使用这个工具包的时候，只会依赖一种数据库。当项目A依赖于项目B的时候，如果其实际使用基于MySQL数据库，那么在项目A中就需要显式地声明mysql-connector-java这一依赖。

最后，关于可选依赖需要说明的一点是，在理想的情况下，是不应该使用可选依赖的。前面我们可以看到，使用可选依赖的原因是某一个项目实现了多个特性，在面向对象设计中，有个单一职责性原则，意指一个类应该只有一项职责，而不是糅合太多的功能。这个原则在规划Maven项目的时候也同样适用。

在上面的例子中，更好的做法是为MySQL和PostgreSQL分别创建一个Maven项目，基于同样的groupId分配不同的artifactId，在各自的POM中声明对应的JDBC驱动依赖，而且不使用可选依赖，用户则根据需要选择使用project-b-mysql或者project-b-postgresql。由于传递性依赖的作用，就不用再声明JDBC驱动依赖。

6.排除依赖

传递性依赖会给项目隐式地引入很多依赖，这极大地简化了项目依赖的管理，但是有些时候这种特性也会带来问题。例如，当前项目有一个第三方依赖，而这个第三方依赖由于某些原因依赖了另外一个类库的SNAPSHOT版本，那么这个SNAPSHOT就会成为当前项目的传递性依赖，而SNAPSHOT的不稳定性会直接影响到当前的项目。这时就需要排除掉该SNAPSHOT，并且在当前项目中声明该类库的某个正式发布的版本。还有一些情况，你可能也想要替换某个传递性依赖，比如Sun JTA API，Hibernate依赖于这个JAR，但是由于版权的因素，该类库不在中央仓库中，而Apache Geronimo项目有一个对应的实现。这时你就可以排除Sun JAT API，再声明Geronimo的JTA API实现。

<dependency>      <groupId>org.apache.hbase</groupId>  <artifactId>hbase</artifactId>  <version>0.94.17</version>   <exclusions>       <exclusion>            <groupId>commons-logging</groupId>              <artifactId>commons-logging</artifactId>       </exclusion>    </exclusions>  </dependency>

在上面的代码中，我们在依赖hbase时，过滤了对commons-logging的传递性依赖。另外，我们可以使用通配符进行多依赖过滤。

<dependency>  <groupId>org.apache.hbase</groupId>  <artifactId>hbase</artifactId>  <version>0.94.17</version>  <exclusions>    <exclusion>      <groupId>*</groupId>      <artifactId>*</artifactId>    </exclusion>  </exclusions></dependency>

在上面的代码中，我们在依赖hbase时，过滤了所有hbase产生的传递性依赖。

7.归类依赖

假设一个项目有很多关于Spring Framework的依赖，它们分别是org.springframework:spring-core:2.5.6、org.springframework:spring-beans:2.5.6、org.springframe-work:spring-context:2.5.6和org.springframework:spring-con-text-support:2.5.6，它们是来自同一项目的不同模块。因此，所有这些依赖的版本都是相同的，而且可以预见，如果将来需要升级Spring Framework，这些依赖的版本会一起升级。

这时，我们应该在一个唯一的地方定义版本，并且在dependency声明中引用这一版本。这样，在升级Spring Framework的时候就只需要修改一处，实现方式如下所示：

<project>       ...    <properties>             <springframework.version>2.5.6</springframework.version>        </properties>       <dependencies>              <dependency>                  <groupId>org.springframework</groupId>                  <artifactId>spring-core</artifactId>                  <version>${springframework.version}</version>            </dependency>            <dependency>                   <groupId>org.springframework</groupId>                   <artifactId>spring-beans</artifactId>                   <version>${springframework.version}</version>        </dependency>            <dependency>                   <groupId>org.springframework</groupId>                   <artifactId>spring-context</artifactId>                   <version>${springframework.version}</version>            </dependency>            <dependency>                   <groupId>org.springframework</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依赖的版本值用这一属性引用表示。

8.依赖优化

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

Maven会自动解析所有项目的直接依赖和传递性依赖，并且根据规则正确判断每个依赖的范围，对于一些依赖冲突，也能进行调节，以确保任何一个构件只有唯一的版本在依赖中存在。在这些工作之后，最后得到的那些依赖被称为已解析依赖（Resolved Depen-dency）。

可以运行如下的命令查看当前项目的已解析依赖：mvn dependency:list。该命令会显示项目的所有已解析依赖，同时，每个依赖的范围也得以明确标示。

在此基础上，还能进一步了解已解析依赖的信息。将直接在当前项目POM声明的依赖定义为顶层依赖，而这些顶层依赖的依赖则定义为第二层依赖，以此类推，有第三、第四层依赖。当这些依赖经Maven解析后，就会构成一个依赖树，通过这棵依赖树就能很清楚地看到某个依赖是通过哪条传递路径引入的。可以运行如下命令查看当前项目的依赖树：mvn dependency:tree。

使用dependency:list和dependency:tree可以帮助我们详细了解项目中所有依赖的具体信息，在此基础上，还有depen-dency:analyze工具可以帮助分析当前项目的依赖。

mvn dependency:analyze命令的结果包含两个部分。

首先是Used undeclared de-pendencies，意指项目中使用到的，但是没有显式声明的依赖。这种依赖意味着潜在的风险，当前项目直接在使用它们，例如有很多相关的Java import声明，而这种依赖是通过直接依赖传递进来的，当升级直接依赖的时候，相关传递性依赖的版本也可能发生变化，这种变化不易察觉，但是有可能导致当前项目出错。例如由于接口的改变，当前项目中的相关代码无法编译。这种隐藏的、潜在的威胁一旦出现，就往往需要耗费大量的时间来查明真相。因此，显式声明任何项目中直接用到的依赖。

另一部分是Unused declared dependencies，意指项目中未使用的，但显式声明的依赖。需要注意的是，对于这样一类依赖，我们不应该简单地直接删除其声明，而是应该仔细分析。由于dependency:analyze只会分析编译主代码和测试代码需要用到的依赖，一些执行测试和运行时需要的依赖它就发现不了。当然，有时候确实能通过该信息找到一些没用的依赖，但一定要小心测试。