转载

Maven基础教程之依赖

这又是一个系列，一个要把Maven讲透的系列，希望能够对大家有帮助！

前言

在前面的总结中，总是说到依赖这个东西，而且还有看到 dependencies 这个词在pom.xml文件中的使用，所以很多读者就很迫不及待的想知道这个依赖到底是什么东西？作为Maven中一个非常重要的概念，那到底该如何使用和配置，以及使用过程中有哪些注意事项，而这篇文章就是对Maven中的依赖进行详细的总结，一扫对依赖概念的不解。

依赖的配置

在Maven中，是在pom.xml文件中完成依赖的配置，我们先来看看依赖配置的语法。

<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 ：用来排除传递性依赖，下面会专门进行总结。

很多时候，大部分依赖声明只包含 groupId 、 artifactId 和 version 这三个指定基本坐标的元素；而在一些特殊情况下，其它元素至关重要，也就是上面提到的 scope 、 optional 和 exclusions 。下面就对这三个要素进行详细的总结。

依赖范围

不知道大家还记不记得在《 Maven基础教程之使用入门》中的这段junit依赖代码：

<dependencies>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.11</version>
        <scope>test</scope>
    </dependency>
</dependencies>

这里就指定了scope这个要素的值，那这里指定这个要素有什么含义呢？

我们需要知道，Maven在编译项目主代码的时候需要使用一套classpath。举例来说：

当Maven编译项目主代码的时候如果需要用到spring-core，该文件以依赖的方式被引入到classpath中；
当Maven编译和执行测试的时候会使用另外一套classpath，则junit文件也会以依赖的方式引入到测试使用的classpath中；
当Maven项目运行时，又会使用一套classpath。

所以依赖范围就是用来控制依赖与这三种classpath（编译classpath、测试classpath、运行classpath）的关系。在Maven中，我们可以针对scope要素设置以下依赖范围：

compile ：编译依赖范围。如果没有指定scope值，就会默认使用该依赖。使用该依赖范围的Maven依赖，对于编译、测试、运行三种classpath都有效；
test ：测试依赖范围。使用此依赖范围的Maven依赖，只对于测试classpath有效，在编译主代码或者运行项目时都无法使用此依赖。对于上面的junit例子，它只有在编译测试代码及运行测试的用例的时候才需要；
provided ：已提供依赖范围。使用此依赖范围的Maven依赖，对于编译和测试classpath有效，但在运行时无效。最典型的例子是servlet-api，编译和测试项目的时候需要该依赖，但在运行项目的时候，由于容器已经提供，就不需要Maven重复地引入一遍；
runtime ：运行时依赖范围。使用此依赖范围的Maven依赖，对于测试和运行classpath有效，但在编译主代码时无效。最典型的例子就是JDBC驱动实现，项目主代码的编译只需要JDK提供的JDBC接口，只有在执行测试或者运行项目的时候才需要实现上述接口的具体JDBC驱动。

system ：系统依赖范围。该依赖与三种classpath的关系和provided依赖范围完全一致。但是，使用system范围的依赖时必须通过systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过Maven仓库解析的，而且往往与本机系统绑定，可能造成构建的不可移植，因此谨慎使用。 system 的使用举例：

<dependency>
    <groupId>com.jellythink.BookStore</groupId>
    <artifactId>BookStore-SSO</artifactId>
    <version>1.0</version>
    <scope>system</scope>
    <systemPath>${basedir}/lib/BookStore-SSO-1.0.jar</systemPath>
</dependency>

对于 system 系统依赖范围，在进行以上配置以后，编写代码时已经可以引入Jar包中的class了，但是在打包时，由于 scope=system ，默认并不会将依赖包打进WAR包中，所有需要通过插件进行打包。例如：

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <version>2.10</version>
    <executions>
        <execution>
            <id>copy-dependencies</id>
            <phase>compile</phase>
            <goals>
                <goal>copy-dependencies</goal>
            </goals>
            <configuration>
                <outputDirectory>${project.build.directory}/${project.build.finalName}/WEB-INF/lib</outputDirectory>
                <includeScope>system</includeScope>
            </configuration>
        </execution>
    </executions>
</plugin>

会了更好的理解和记忆依赖范围与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仓库之外的类库文件

依赖传递的几个注意事项

说到依赖传递，这里的关系就比较复杂，在没有使用Maven之前，大家是否有这样的开发体验；比如引入了包A，由于我们不知道包A的依赖，只能在编译的时候，根据出错信息，再加入需要的其它依赖，很显然，这样的开发体验是及其糟糕的。而现在有了Maven，Maven中的传递性依赖机制可以很好的解决这一问题。这里就来详细的总结Maven中的依赖传递。

啥是依赖传递

在实际项目中，我们肯定会遇到如下图所示的这种依赖情况：

A依赖B，B又依赖C。由于基于Maven创建的项目，有了传递性依赖机制，在使用A的时候就不用去考虑A依赖了什么，也不用担心引入多余的依赖。Maven会解析各个直接依赖的POM，将那些必要的间接依赖，以传递性依赖的形式引入到当前的项目中。
依赖传递的范围

在传递性依赖中，如上图所示的A依赖B，B依赖C，我们就说A与B是第一直接依赖，B与C是第二直接依赖，C对于A是传递性依赖。第一直接依赖的范围和第二直接依赖的范围决定了传递性依赖的范围，下面通过一张表格来说明这种传递性依赖范围：

对于上面的图，最左面的一列表示第一直接依赖范围，最上面一行表示第二直接依赖范围。比如A对B的依赖scope是compile，B对C的依赖scope是runtime，那么A对C的依赖scope就是runtime。如下图标注所示：

在实际使用过程中，对于这个依赖传递范围的关注还是比较少的，在以后的使用过程中，如果遇到问题，我们应该能想到这里总结的依赖传递范围相关的知识点。
依赖调解

先来说一个实际开发过程中经常会遇到的两个问题。

问题一：比如项目A有这样的两个依赖关系：

从上图可以看到，项目A有两条依赖关系，X是A的传递性依赖，但是你会发现两条依赖路径上有两个版本的X，那么哪个X会被Maven解析使用呢？两个版本都被解析显然是不对的，因为那会造成依赖重复，因此必须选择一个。这种问题，该如何解决呢？

问题二：比如项目A有这样的两个依赖关系：

对于这种情况，和问题一的区别就是X作为A的传递性依赖，两个版本的依赖路径长度是一样的，都是2，这情况下，那么到底谁又会被解析呢？

这里就涉及到Maven中的依赖调解了，当出现上述的两个问题时，Maven就会运用内置的两个调解原则，确定到底哪个依赖会被最终解析使用。这两个内置的调解原则如下：
1. 路径最短者优先；对于问题一，X(1.0)的路径长度为2，X(2.0)的路径长度为3，按照该路径最短者优先原则，则X(1.0)会被解析使用；
2. 第一声明者优先；对于问题二，在依赖路径长度相等的情况下，在pom.xml中依赖声明的顺序决定了谁会被解析使用，顺序最靠前的那个依赖优胜。
可选依赖

在Maven的世界里，存在着这样的一种依赖关系，如下图所示：

从上图可以看到，M和N对于B都是可选依赖，依赖将不会进行依赖范围传递，也就是说，如果A需要使用M或N时，还需要在pom.xml中显示的进行声明。

既然可选依赖没有依赖范围传递，导致我们需要人工不得不去进行一些显示的依赖声明，那为什么还要使用可选依赖这一特性呢？存在即合理！我们想象这样的一种场景，项目B实现了两个特性，其中的一个特性依赖于M，另一个特性依赖于N，而且这两个特性是互斥的，用户不可能同时使用这两个特性。比如B是一个持久层隔离工具包，它支持多种数据库，包括MySQL、PostgreSQL等，在构建这个工具包的时候，需要这两种数据库的驱动程序，但在使用这个工具包的时候，只会依赖一种数据库。这种情况下，项目B的依赖声明就会是这样的：
```
<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.jellythink.BookStore</groupId>
    <artifactId>project-B</artifactId>
    <version>1.0.0</version>
    <dependencies>
        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
            <version>8.0.15</version>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>postgresql</groupId>
            <artifactId>postgresql</artifactId>
            <version>9.1-901-1.jdbc4</version>
            <optional>true</optional>
        </dependency>
    </dependencies>
</project>
```
上述pom.xml代码片段中，使用 <optional> 元素表示mysql和postgresql这两个依赖为可选依赖，这样一来，它们只会对当前的项目B产生影响，当其它项目依赖于B的时候，这两个依赖不会被传递。因此，当项目A依赖于项目B的时候，如果其实际使用基于MySQL数据库，那么在项目A中就需要显式地声明mysql依赖，比如这样：
```
<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.jellythink.BookStore</groupId>
    <artifactId>project-A</artifactId>
    <version>1.0.0</version>
    <dependencies>
        <dependency>
            <groupId>com.jellythink.BookStore</groupId>
            <artifactId>project-B</artifactId>
            <version>1.0.0</version>
        </dependency>
        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
            <version>8.0.15</version>
        </dependency>
    </dependencies>
</project>
```
看完上面关于可选依赖的总结，大家都会觉的可选依赖确实非常麻烦，本来使用Maven是为了提升开发效率的，现在到好，搞的更复杂了；所以，在理想的情况下，是不应该使用可选依赖的。通过上面的例子可以看到，使用可选依赖的原因是某一个项目实现了多个特性，在面向对象设计中，有个单一职责性原则，意指一个类应该只有一项职责，而不是糅合太多的功能。这个原则在规划Maven项目的时候也同样适用。这样，对于上面的例子，更好的做法是为MySQL和PostgreSQL分别创建一个Maven项目，基于同样的groupId分配不同的artifactId，在各自的POM中声明对应的JDBC驱动依赖，而且不使用可选依赖，这样用户则根据需要选择使用对应的依赖即可。

实战经验分享

Maven的依赖涉及的知识点比较多，结合上面整理的内容，再通过结合前人的经验，这里分享一些实战经验，方便大家更好的理解和使用Maven。

排除依赖

通过上面的总结，大家可以感受到传递性依赖带来的便利，但是有些时候这种特性也会带来问题。大家想象一下现在的这个应用场景。当前项目有一个第三方依赖，而这个第三方依赖由于某些原因依赖了另外一个类库的SNAPSHOT版本，那么这个SNAPSHOT就会成为当前项目的传递性依赖，而SNAPSHOT的不稳定性会直接影响到当前项目。这时就需要排除该SNAPSHOT版本，并且在当前项目中声明该类库的某个正式发布的版本。这种情况就需要使用到Maven中的排除依赖了，通过 exclusion 关键字来排除对应的依赖。代码片段如下：
```
<project>
    <modelVersion></modelVersion>
    <groupId>com.jellythink.BookStore</groupId>
    <artifactId>project-A</artifactId>
    <version>1.0.0</version>
    <dependencies>
        <dependency>
            <groupId>com.jellythink.BookStore</groupId>
            <artifactId>project-B</artifactId>
            <version>1.0.0</version>
            <exclusions>
                <exclusion>
                    <groupId>com.jellythink.BookStore</groupId>
                    <artifactId>project-C</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>com.jellythink.BookStore</groupId>
            <artifactId>project-C</artifactId>
            <version>1.1.0</version>
        </dependency>
    </dependencies>
</project>
```
上面代码的依赖逻辑如下图所示：

项目A依赖于项目B，但是由于某些原因，不想引入传递性依赖C，而是自己显式地声明对于项目C 1.1.0版本的依赖。代码中使用 exclusions 元素声明排除依赖， exclusions 可以包含一个或者多个 exclusion 子元素，因此可以排除一个或者多个传递性依赖。需要注意的是，声明 exclusion 的时候只需要 groupId 和 artifactId ，而不需要 version 元素，这是因为只需要 groupId 和 artifactId 就能唯一定位依赖图中的某个依赖。换句话说，Maven解析后的依赖中，不可能出现 groupId 和 artifactId 相同，而 version 不同的两个依赖。

归类依赖

现在很多应用都是基于Spring框架开发，但是使用Spring框架时，就需要引入多个Spring框架的依赖，比如这样子的：

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.jellythink.BookStore</groupId>
    <artifactId>project-A</artifactId>
    <version>1.0.0</version>
    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-core</artifactId>
            <version>5.1.6.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-beans</artifactId>
            <version>5.1.6.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
            <version>5.1.6.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context-support</artifactId>
            <version>5.1.6.RELEASE</version>
        </dependency>
    </dependencies>
</project>

可以看到，这些依赖都是Spring框架的不同模块，在实际项目中，所有这些依赖的版本都是相同的，而且可以预见，如果将来需要升级Spring框架，这些依赖的版本会一起升级。按照上面的代码片段，我们需要所有Spring框架模块的 version 字段，这样一个一个的修改增加了错误发生的概率。此时，我们可以使用Maven中的归类依赖，通过引入Maven属性来简化这个问题。对于上面的代码片段，我们可以这样修改：

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.jellythink.BookStore</groupId>
    <artifactId>project-A</artifactId>
    <version>1.0.0</version>

    <properties>
        <springframework.version>5.1.6.RELEASE</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>

这里使用 properties 元素定义Maven属性，在pom.xml中可以使用美元符号和大括弧环绕的方式引用Maven属性。

优化依赖

在软件开发的过程中，我们通过工具来简化我们的工作，提升我们的工作效率，而Maven就是这样的一个工具。对于工具，有的时候，我们不能仅仅停留在使用的层面，而是能够掌控工具。

通过前面的总结，我们知道Maven会自动解析所有项目的直接依赖和传递性依赖，并且根据规则正确判断每个依赖的范围，对于一些依赖冲突，也能进行调节，以确保任何一个构件只有唯一的版本在依赖中存在。在这些工作之后，最后得到的那些依赖被称为“已解析依赖”。我们可以通过以下命令查看当前项目的已解析依赖以及依赖范围：
```
mvn dependency:list
```
我们还可以通过以下命令查看项目的依赖树，通过这棵依赖树就能很清楚地看到某个依赖是通过哪条传递路径引入的：
```
mvn dependency:tree
```
使用 dependency:list 和 dependency:tree 可以帮助我们详细了解项目中所有依赖的具体信息，在此基础上，还有 dependency:analyze 工具可以帮助分析当前项目的依赖。
```
mvn dependency:analyze
```
dependency:analyze 命令的输出结果中有两个重要的部分。首先是Used undeclared dependencies，指的是项目中使用到的，但是没有显式声明的依赖。这种依赖是通过直接依赖传递进来的，当升级直接依赖的时候，相关传递性依赖的版本也可能发生变化，这种变化不易察觉，但是有可能导致当前项目出错；因此，显式声明任何项目中直接用到的依赖。

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

总结

现在回头一看，Maven中依赖的知识点还真不少，虽然Maven中关于依赖的知识点很多，但是实际用到的，需要我们重点关注的内容是很少的，本文中有些概念我们只需要知道和理解就OK了。这篇文章非常的长，内容多，知识点也多，希望大家还是有点耐心，好好的阅读一下，争取一次就把Maven的依赖概念理解到位，一次学会，终生受益。希望你能喜欢这篇文章。

果冻想，玩代码，玩技术！

2019年4月7日，于内蒙古呼和浩特。

Maven基础教程之依赖