Maven依赖配置和依赖范围

< 上一页Maven配置镜像仓库 Maven的排除依赖、归类依赖和优化依赖下一页 >

教程前面用坐标一一对应地描述了构件，并且保存在仓库中了。那用坐标描述好后，把它们放在仓库中的作用是什么呢？

当其他项目需要在这些构件的基础上做开发的时候，用户就没必要自己再重新实现一遍了。直接指定坐标，告诉 Maven 将坐标对应的构件从仓库中找出来，集成到新项目中就可以了。这时候引入的构件，就是新项目的依赖。

依赖一般分以下两个层次理解：

1）在 Maven 项目的 pom.xml 中配置所需要构件的坐标，也就是配置依赖。还有就是 Maven 在构建项目的时候，根据坐标从仓库中找到坐标所对应的构件文件，并且把它们引入 Maven 项目中来，也就是 Maven 引用。

2）由 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>

通过前面依赖配置样例会发现，依赖配置中除了构件的坐标信息、groupId、artifactId 和 version 之外，还有其他的元素。接下来就简单介绍一下这些元素的作用。

groupId、artifactId 和 version：依赖的基本坐标。对于任何依赖，基本坐标是最基本、最重要的，因为 Maven 是根据坐标找依赖的。
type：依赖的类型，同项目中的 packaging 对应。大部分情况不需要声明，默认是 jar。
scope：依赖的范围，详细情况后面介绍。
optional：标记依赖是否可选，详细情况后面介绍。
exclusions：排除传递性依赖，详细情况后面介绍。

依赖的范围

Java 中有个环境变量叫 classpath。JVM 运行代码的时候，需要基于 classpath 查找需要的类文件，才能加载到内存执行。

Maven 在编译项目主代码的时候，使用的是一套 classpath，主代码编译时需要的依赖就添加到这个 classpath 中去；Maven 在编译和执行测试代码的时候，又会使用一套 classpath，这个动作需要的依赖就添加到这个 classpath 中去；Maven 项目具体运行的时候，又有一个独立的 classpath，同样运行时需要的依赖，肯定也要加到这个 classpath 中。这些 classpath，就是依赖的范围。

依赖的范围，就是用来控制这三种 classpath 的关系（编译 classpath、测试 classpath 和运行 classpath），接下来分别介绍依赖的范围的名称和意义。

1）compile

编译依赖范围。如果在配置的时候没有指定，就默认使用这个范围。使用该范围的依赖，对编译、测试、运行三种 classpath 都有效。

2）test

测试依赖范围。使用该范围的依赖只对测试 classpath 有效，在编译主代码或运行项目的时候，这种依赖是无效的。

3）provided

已提供依赖范围。使用此范围的依赖，只在编译和测试 classpath 的时候有效，运行项目的时候是无效的。比如 Web 应用中的 servlet-api，编译和测试的时候就需要该依赖，运行的时候，因为容器中自带了 servlet-api，就没必要使用了。如果使用了，反而有可能出现版本不一致的冲突。

4）runtime

运行时依赖范围。使用该范围的依赖，只对测试和运行的 classpath 有效，但在编译主代码时是无效的。比如 JDBC 驱动实现类，就需要在运行测试和运行主代码时候使用，编译的时候，只需 JDBC 接口就行。

5）system

系统依赖范围。该范围与 classpath 的关系，同 provided 一样。但是，使用 system 访问时，必须通过 systemPath 元素指定依赖文件的路径。因为该依赖不是通过 Maven 仓库解析的，建议谨慎使用。

如下代码是一个使用 system 范围的案例。

<dependency>
    <groupId>xxx</groupId>
    <artifactId>xxx</artifactId>
    <version>xx</version>
    <scope>system</scope>
    <systemPath>e:/xxxx/xxx/xx.jar</systemPath>
</dependency>

6）import

导入依赖范围。该依赖范围不会对三种 classpath 产生实际的影响。它的作用是将其他模块定义好的 dependencyManagement 导入当前 Maven 项目 pom 的 dependencyManagement 中。比如有个 SpringPOM Maven 工程，它的 pom 中的 dependencyManagement 配置如下：

<project>
    ...
    <groupId>cn.com.mvn.pom</groupId>
    <artifactId>SpringPOM</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <packaging>pom</packaging>
    ...
    <dependencyManagement>
        <dependencies>
            <!-- spring -->
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-core</artifactId>
                <version>${project.build.spring.version}</version>
            </dependency>

            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-aop</artifactId>
                <version>${project.build.spring.version}</version>
            </dependency>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-beans</artifactId>
                <version>${project.build.spring.version}</version>
            </dependency>
        </dependencies>
    </dependencyManagement>
    ...
</project>

接下来创建一个新的 Maven 工程 Second，要将 First 工程中 pom 中定义的 dependency-Management 原样合并过来，除了复制、继承之外，还可以编写如下代码，将它们导入进去。

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>cn.com.mvn.pom</groupId>
            <artifactId>SpringPOM</artifactId>
            <version>0.0.1-SNAPSHOT</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

传递性依赖

在使用 Maven 之前，如果要基于 Spring 框架开发项目，除了要加入 Spring 框架的 jar 包外，还需要将 Spring 框架所用到的第三方 jar 包加入。否则编译通过，但是运行的时候就会出现 classNotFound 异常。

为了解决这种问题，一般有两种方式：一种是下载 Spring 的 dependencies.zip 包，将其中的所有 jar 包都导入工程；另一种是根据运行时的报错信息，确定哪些类没有，再将包含这些类的 jar 包下载下来导入。

第一种方式虽然可以一次性解决所有需要 jar 包的导入问题，但是当查看工程的 jar 包会发现，有不少多余的 jar 包。这些多余的 jar 包不仅仅加大了项目的体积，还有可能同其他框架所导入的 jar 包有版本冲突。

第二种方式虽然不会有多余的 jar 包存在，但是要根据每次启动的错误，一个个找到 jar 包，再导入。想象如果有 10 个 jar 包，就要启动 10 次，查看 10 次错误分别导入，有多麻烦。

Maven 的传递依赖机制就能解决这样的问题。

当项目基于 Spring 框架实现的时候，只需将 Spring 的依赖配置到 pom 的依赖元素就行。至于 Spring 框架所依赖的第三方 jar 包，用户不用处理，Maven 自己通过检测 Spring 框架的依赖信息将它们导入项目中来。而且只会导入 Spring 框架所需要的，不会导入多余的依赖。

也就是说，Maven 会解析项目中的每个直接依赖的 pom，将那些必要的间接依赖以传递依赖的形式引入项目中。

当然，传递依赖在将间接依赖引入项目的过程中也有它自己的规则和范围。这个规则和范围是同前面介绍的依赖范围紧密关联的。

现在有三个项目（A、B 和 C 项目），假设 A 依赖 B，B 依赖 C，这样把 A 对 B 的依赖叫第一直接依赖，B 对 C 的依赖叫第二直接依赖，而 A 对 C 的依赖叫传递依赖（通过 B 传递的）。

中间 A 到 B 第一直接依赖的范围和 B 到 C 第二直接依赖的范围，就共同决定了 A 到 C 的传递依赖范围。它们的影响效果，就如表 1 所示。

坐标第一列表示第一直接依赖的范围，第一行表示第二直接依赖的范围，中间的交叉点为共同影响后的传递依赖的范围。

表 1 依赖的传递
依赖	compile	test	provided	runtime
Compile	compile	--	--	runtime
test	test	--	--	test
provided	provided	--	provided	provided
runtime	runtime	--	--	runtime

通过前面的表格，可以得出如下规律。

当第二直接依赖为 compile 的时候，传递依赖同第一直接依赖一致。
当第二直接依赖为 test 的时候，没有传递依赖。
当第二直接依赖为 provided 的时候，值将第一直接依赖中的 provided 以 provided 的形式传递。
当第二直接依赖为 runtime 的时候，传递依赖的范围基本上同第一直接依赖的范围一样，但 compile 除外，compile 的传递依赖范围为 runtime。

依赖的调解

在使用 Maven 自动提供的传递依赖后，可以解决对应的依赖管理，特别是间接依赖管理中遇到的问题。但是，当多个直接依赖都带来了同一个间接依赖，而且是不同版本的间接依赖时，就会引起重复依赖，甚至包冲突的问题。

那么，Maven 在传递依赖的时候是按什么规则来的呢？

1. 依赖调解原则

Maven 依赖调解原则有两个：一个是路径优先原则；另一个是声明优先原则。当路径优先原则搞不定的时候，再使用声明优先原则。

比如有个项目 A，它有两个依赖：A→B→C→T（1.0），A→D→T（2.0）。会发现，A 最终对 T（1.0）和 T（2.0）都有间接依赖。这时候 Maven 会自动判断它的路径，发现 T（2.0）的路径长度为 2，T（1.0）的路径长度为 3，以最短路径为原则，将 T（2.0）引入当前项目 A。

如果有个项目 A，它有两个依赖：A→B→T（1.0），A→C→T（2.0）。这时候两条路径都是一样的长度 2，那 Maven 到底把哪个引入项目 A 呢？这时候 Maven 会判断哪个依赖在 pom.xml 中先声明，选择引入先声明的依赖。

2．可选依赖

在实际项目中，存在一些比较特殊的依赖。比如数据访问层模块对数据库驱动的依赖就比较特殊了。DAO 层要访问数据库的时候，需要加入数据库驱动依赖，而且不同数据库驱动依赖是不一样的。如果在设计 DAO 层的时候，是按跨数据库标准实现的，这就引出了一个新问题，是在 pom.xml 中配置 MySQL 驱动依赖呢？还是配置 Oracle 驱动依赖？或者两个都配置？

其实仔细想想，前面三种选项都不合适。单独配置 MySQL 或 Oracle，这样就不能跨数据库了。两个数据库都配置，驱动之间就会有冲突，或有多余的依赖。

这时候，就直接把这两个数据库驱动的依赖都设置成可选依赖，代码如下：

<dependencies>
    <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <version>5.1.34</version>
        <optional>true</optional>
    </dependency>
    <dependency>
        <groupId>oracle</groupId>
        <artifactId>ojdbc14</artifactId>
        <version>10.2.0.4</version>
        <optional>true</optional>
    </dependency>
</dependencies>

在应用项目中再具体指定使用哪个依赖，例如：

<dependencies>
    <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <version>5.1.34</version>
    </dependency>
</dependencies>

需要说明的是，在实际项目中建议不要使用可选依赖。虽然可选依赖满足了对一个模块的特征多样性，同时还提供了更多的选择，但是在实际配置中，好像不仅没有减少配置代码，还增多了重复复制的机会。

同时从面向对象分析和设计的思路来说，也是建议遵循单一职责原则，也就是一个类只有一个功能，不要糅合太多的功能，这样不方便理解、开发和维护。

所以实际项目中，一般对不同数据库的驱动单独创建一个 Maven 工程。其他项目需要基于哪个数据库进行操作的话，引用对应的 Maven 的工程以来就行，用传递依赖引入需要的数据库驱动依赖。