【Maven】依赖管理

4. Maven的依赖管理

在 Java 开发中，项目的依赖管理是一项重要任务。通过合理管理项目的依赖关系，我们可以有效的管理第三方库，模块的引用及版本控制。而 Maven 作为一个强大的构建工具和依赖管理工具，为我们提供了便捷的方式来管理项目的依赖。

4.1 什么是依赖范围

• Maven 的依赖构件包含一个依赖范围的属性。
• 这个属性描述的是三套 classpath 的控制，即编译、测试、运行，也就是添加的 jar 包起作用的范围。
• Maven 提供了以下几种依赖范围：compile、test、provided、runtime、system。
• 在 pom.xml 文件中使用 标签指定依赖范围类型。

1、compile

编译依赖范围。

依赖范围对于编译、测试、运行 3 种 classpath 都有效。如果没有指定，默认使用该依赖范围。

也就是说，compile 在整个项目下和运行时都有效，Maven 都会帮助导包：

2、test

测试依赖范围。

此依赖范围只对编译测试、运行测试的 classpath 有效，在编译主代码、运行项目时无法使用此类依赖。比如 junit，它只有在编译测试代码、运行测试时才需要。

当依赖范围是 test 时：

• 在 src/test 目录下，Maven 会帮忙导入这些包。
• 出了此范围，Maven 不会导包。

示例：

在 maven_01_javase 模块中，我们在 pom.xml 中引入 junit 依赖，并指定依赖范围为 test：

这时候，我们可以在 src/test 包下的测试类 MathCalculateTest 中导入 junit 包：

然后，把 MathCalculateTest 类复制粘贴到 src/main 包下，发现无法将 junit 包导入到类中。这是因为，junit 的依赖范围是 test，它只能在 src/test 包下引入。

3、provided

已提供依赖范围。

此依赖范围对于编译源码、编译测试、运行测试中 classpath 有效，但在运行时无效，因为项目的运行环境中已经提供了所需要的构件。比如上面说到的 servlet-api，这个在编译和测试的时候需要用到，但是在运行的时候，Web 容器已经提供了，就不需要 Maven 帮忙引入了。Tomcat 服务器就提供了 servlet-api：

示例：

1、在 maven_03_javawebnew 模块中，我们在 pom.xml 文件中，引入了 servlet、junit、和 MyBatis，并分别指定依赖范围为 provided、test 和 compile。

2、然后，我们将 maven_03_javawebnew 模块打包，以观察 war 包中的 jar 包引入情况。

3、打包后，得到了模块的 war 包：

4、将 war 包后缀修改为 rar 压缩包格式，并打开，发现只有一个 MyBatis 的 jar 包：

因此，在打包时，compile 依赖范围的 jar 包 Maven 会帮忙引入；而 test 和 provided 依赖范围的 jar 包 Maven 不会引入。

4、runtime

运行时依赖范围。

此依赖范围对于测试和运行项目的 classpath 有效，但在编译时无效，比如 JDBC 驱动实现，项目代码编译的时候只需要使用 JDK 提供的 JDBC 接口，运行的时候才需要具体的 JDBC 驱动实现。

<dependencies>
  <dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>5.1.32</version>
    <scope>runtime</scope>
  </dependency>
</dependencies>

5、system

系统依赖范围。

此依赖直接依赖于本地路径。可能每个开发者机器中构件的路径不一致，如果使用这种写法，你的机器中可能没有问题，别人的机器中就会有问题，所以建议谨慎使用。

需要使用 标签显式地指定依赖文件的路径。

总测试：

1、在 maven_03_javawebnew 模块中，引入 5 种类型的依赖：

<dependencies>

  <!--添加 Servlet 的依赖-->
  <dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>javax.servlet-api</artifactId>
    <version>4.0.1</version>
    <scope>provided</scope>
  </dependency>

  <!--添加 junit 的依赖-->
  <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.13.2</version>
    <scope>test</scope>
  </dependency>

  <!--添加 MyBatis 的依赖-->
  <dependency>
    <groupId>org.mybatis</groupId>
    <artifactId>mybatis</artifactId>
    <version>3.5.11</version>
    <scope>compile</scope>
  </dependency>

  <!--添加 MySQL 的依赖-->
  <dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>5.1.32</version>
    <scope>runtime</scope>
  </dependency>

  <!--添加 maven_01_javase 的依赖-->
  <dependency>
    <groupId>cn.myphoenix</groupId>
    <artifactId>maven_01_javase</artifactId>
    <version>1.0-SNAPSHOT</version>
    <scope>system</scope>
    <systemPath>C:/Coding_Gallery/Intellij_IDEA_Workspace/learning_maven/maven_01_javase/target/maven_01_javase-1.0-SNAPSHOT.jar</systemPath>
  </dependency>
  
</dependencies>

2、将 maven_03_javawebnew 打包，观察 jar 包引入情况：

发现只有 complie 和 runtime 类型的依赖可以导入，其他 3 种类型未导入。

作用范围总结：

依赖范围的再理解：

在项目中引入依赖的同时，我们可以为依赖指定依赖范围。从这个角度来看，依赖范围就是当前项目希望引入的依赖（jar 包）在什么范围内起作用，在什么范围内不起作用。

4.2 什么是依赖传递

依赖具有传递性。

Maven 的依赖传递机制：不管 Maven 项目存在多少间接依赖，POM 中都只需要定义其直接依赖，不必定义任何间接依赖，间接依赖都由 Maven 自动导入，这在一定程度上简化了 POM 的配置。

假项目 A 依赖项目 B，项目 B 依赖项目 C，则 A 直接依赖 B，B 直接依赖 C，而 A 间接依赖 C。

示例：说明间接依赖

现在，maven_01_javase 模块中引入了 junit 1 个依赖。为了演示直接依赖和间接依赖，现在在该模块中引入 spring-context 依赖。

引入依赖后，发现 spring-context 这个一级依赖下又引入了多个间接依赖，这些间接依赖都是由 Maven 自动引入的。

4.2.1 依赖范围对依赖传递的影响

B 是 A 的直接依赖，C 是 A 的间接依赖，根据 Maven 的依赖传递机制，间接依赖 C 会以传递性依赖的形式引入到 A 中，但这种引入并不是无条件的，它会受到依赖范围的影响。

举例说明：本例子依据为下图

1、创建 2 个项目 maven_laoda 和 maven_mazai，在 maven_laoda 引入 maven_mazai，则 maven_mazai 是 maven_laoda 的直接依赖；在 maven_mazai 中引入 MyBatis 依赖，则 MyBatis 是 maven_laoda 的间接依赖。

2、在 maven_mazai 中执行 install，将 maven_mazai 安装到本地仓库（在公司中是安装到私服），然后，在 maven_laoda 中通过 GAV 引入 maven_mazai 依赖。

3、在 maven_laoda 的 pom.xml 中为 maven_mazai 设置不同的依赖范围。同时，在 maven_mazai 的 pom.xml 中为 MyBatis 设置不同的依赖范围。观察：

• 在 maven_laoda 中能否引入间接依赖 MyBatis
• 如果能引入，那么间接依赖 MyBatis 的依赖范围类型是什么

接下来进行测试。固定间接依赖的类型，变动直接依赖的类型。

测试 1：间接依赖为 compile，直接依赖为 compile。

测试结果：间接依赖被引入到 maven_laoda 中；依赖范围是 compile。

测试 2：间接依赖为 compile，直接依赖为 test。

测试结果：间接依赖被引入到 maven_laoda 中；依赖范围是 test。

……

测试 n：间接依赖为 test，直接依赖为 compile。

测试结果：间接依赖没有被引入到 maven_laoda 中。

……

测试 n + m：间接依赖为 provided，直接依赖为 compile。

测试结果：间接依赖没有被引入到 maven_laoda 中。

……

测试 n + k：间接依赖为 runtime，直接依赖为 compile。

测试结果：间接依赖被引入到 maven_laoda 中；依赖范围是 runtime。

总结：

1. 当间接依赖的范围是 compile 时，间接依赖在项目中的范围与直接依赖的范围一致；
2. 当间接依赖的范围是 test 或 provided时，间接依赖不会被传递；
3. 当间接依赖的范围是 runtime 时，间接依赖在项目中的范围与直接依赖的范围一致，但 compile 例外，此时间接依赖在项目中的范围为 runtime。

4.3 依赖冲突

4.3.1 什么是依赖冲突

在 Maven 项目中，依赖通常被定义在项目的 pom.xml 文件中。当引入同一个依赖的多个不同版本时，就会发生依赖冲突。

这可能是因为项目的直接依赖和间接依赖导致了同一库的多个版本存在于类路径中。每个显式声明的类包都会依赖于一些其他的隐式类包，这些隐式的类包会被 Maven 间接引入进来，从而造成类包冲突。

4.3.2 依赖冲突的解决方案

Maven 可以通过以下途径解决依赖冲突。

4.3.2.1 版本锁定

在父工程中使用 标签进行版本锁定。

• dependencyManagement 可以统一管理整个项目的版本号，确保项目的各个模块的依赖版本一致。
• dependencyManagement 只是声明依赖，并不会在项目中引入依赖。
• 子项目需要显式地声明需要用的依赖，可以不指定版本，其与项目声明的版本一致。
• 如果排斥父工程中定义的版本号，可以显式地进行版本号声明。

示例：

1、创建 maven_parent 模块，在该模块下创建子模块 maven_son，观察两个模块的 pom.xml 文件：

• 父模块指定了 GAV；子模块只指定了 A，其 G 和 V 继承自父模块。
• 在父模块中，声明了子模块；在子模块中，声明了父模块。
• 父模块中指明了打包方式是 pom。pom 是父工程的打包方式，此工程不能运行，只是来进行规范和定义的。
  

2、在 maven_parent 模块的 pom.xml 文件中，使用 dependencyManagement 声明 junit 依赖的版本（红框）。然后，在子模块 maven_son 的 pom.xml 文件中引入 junit 依赖，不需要指明版本，使用父模块中声明的版本（橙色框）。

另外，可以看到父模块并没有引入 junit 依赖（绿框）。

3、（可选）可以在子模块中指定 junit 的版本，而不使用父模块中声明的版本。但这样做的意义不大，因为使用 dependencyManagement 就是要做版本锁定的。

4、（继承）可以不使用 dependencyManagement，而是直接在父模块中使用 dependency 引入依赖。这样的话，子模块不需要显式地引入依赖，因为它会继承父模块的所有依赖。

dependencyManagement 的版本锁定可以在子模块中按需引入依赖，而继承****会使子模块拥有父模块的所有依赖，使子模块依赖变得臃肿。

4.3.2.2 短路径优先

路径短者优先引入。顾名思义，当一个间接依赖存在多条引入路径时，引入路径短的会被解析使用。如下图所示，maven_02 会引入 junit 的 4.12 版本而不是 4.13 版本。

示例：

1、创建模块 maven_02 和 maven_03。

2、在 maven_02 中引入 junit 4.12 版本。

3、执行 install，将 maven_03 安装到本地仓库，在 maven_02 中引入 maven_03。

3、在 maven_03 中引入 junit 4.13 版本。

结果如下，在 maven_02 中引入直接依赖 junit 4.12，而丢弃间接依赖 junit 4.13：

4.3.2.3 声明优先

如果存在短路径，则优先选择短路径。如果路径相同，则先声明者优先，POM 文件中依赖声明的顺序决定了间接依赖会不会被解析使用，顺序靠前的优先使用。如下图所示：

示例：

1、创建模块 maven_01、maven_04 和 maven_05。

2、在 maven_04 中引入 junit 4.13 版本；在 maven_05 中引入 junit 4.12 版本。

3、执行 install，将 maven_04 和 maven_05 安装到本地仓库，在 maven_01 中引入 maven_04 和 maven_05。

结果如下：

• 如果 maven_04 的 GAV 在前，则 maven_01 中引入间接依赖 junit 4.13，而丢弃间接依赖 junit 4.12；
• 如果 maven_05 的 GAV 在前，则 maven_01 中引入间接依赖 junit 4.12，而丢弃间接依赖 junit 4.13。

4.3.2.4 特殊优先（后来者居上）

在同一个 pom.xml 文件中，对同一个 jar 包进行了多次不同版本的配置，后面的版本覆盖前面的版本。这种情况比较少见。

示例：

1、创建模块 maven_06。

2、在 maven_06 的 pom.xml 文件中依次引入 junit 4.13、4.8.2 和 4.12 版本。

结果如下，在 maven_06 中引入直接依赖 junit 4.12，而覆盖了 junit 4.8.2 和 junit 4.13：

4.3.2.5 可选依赖

使用 标签禁止传递间接依赖。

如果当前项目被依赖到其它项目中，当前项目可以拒绝交出间接依赖项。如下图所示，maven_07 添加了 maven_08 的依赖，maven_08 可以自主设置其依赖项 junit 4.13 是否被间接传递。true 为不传递间接依赖，那么在 maven_07 项目中就没有 junit 4.13 的依赖。默认是 false，传递间接依赖。

示例：

1、创建模块 maven_07 和 maven_08。

2、在 maven_08 的 pom.xml 文件中引入 junit 4.13 版本。

3、执行 install，将 maven_08 安装到本地仓库，在 maven_07 中引入 maven_08。

结果如下，在 maven_07 中引入了直接依赖 maven_08，但没有引入间接依赖 junit 4.13：

4.3.2.6 排除依赖

当前项目主动排除其依赖项目的间接依赖。也就是控制当前项目是否使用其直接依赖传递下来的接间依赖。如下图所示，在 maven_09 项目中添加 maven_10 项目的依赖，但不要 maven_10 项目中的 junit 4.13 依赖，可以使用排除依赖，这样可以保证当前项目依赖的纯净性。

排除依赖使用 exclusions 元素排除依赖：

• exclusions 元素下可以包含若干个 exclusion 子元素，用于排除若干个间接依赖，该元素包含两个子元素：groupId 和 artifactId，用来确定需要排除的间接依赖的坐标信息。
• exclusion 元素中只需要设置 groupId 和 artifactId 就可以确定需要排除的依赖，无需指定版本 version，也无法指定版本 version

示例：

1、创建模块 maven_09 和 maven_10。

2、在 maven_10 的 pom.xml 文件中引入 junit 4.13 版本。

3、执行 install，将 maven_10 安装到本地仓库，在 maven_09 中引入 maven_10。

结果如下，在 maven_09 中引入了直接依赖 maven_10，但没有引入间接依赖 junit 4.13：

附：可选依赖和排除依赖的区别

排除依赖和可选依赖都能在项目中将间接依赖排除在外，但两者实现机制却完全不一样。

• 可选依赖是自己决定是否向外提供间接依赖。
• 排除依赖是主动拒绝添加直接依赖关联的间接依赖。
• 可选依赖的优先级高于排除依赖
• 若对于同一个间接依赖同时使用排除依赖和可选依赖，那么可选依赖的取值必须为 false，否则排除依赖无法生效。

4.4 Intellij IDEA刷新依赖的8种方式

在 IDEA 中有时候会出现刷新延时的情况，那么需要进行手工刷新依赖。

1. 点击 M 刷新按钮。
2. 点 Maven 窗口的 Reload All Maven Projects。
3. Build —> ReBuild Project 重新构建项目的同时刷新所有依赖。
4. 点击本项目的 pom.xml 文件 —> 右键 —> Maven —> Reload Project 刷新本项目的依赖。
5. 打开 pom.xml 文件，全选、拷贝、删除、关闭、打开、粘贴，物理刷新 pom.xml 文件 。
6. Invalidate Caches —> 全选 —> Invalidate and Restart 清空 IDEA 的缓存并重启 IDEA 刷新依赖。
7. 打开本地仓库，搜索 last，全选删除，点 Maven 的刷新全部依赖的按钮。
8. 在 7 的步骤后执行 File —> settings —> Build,Execution,Deployment —> Build Tools —> Maven —> Repositories —> 选中本地仓库 —> update —> OK。

4.5 资源文件的指定

问题：

• src/main/java 和 src/test/java 这两个目录中的所有 *.java 文件会分别在 comile 和 test-comiple 阶段被编译，编译结果分别放到了 target/classes 和 targe/test-classes 目录中。但是这两个目录中的其他文件（后缀是 .properties 或 .xml 等文件）都会被忽略掉（编译后丢失）。
• 简单来说就是在 resources 目录下的 *.properties 文件和 *.xml 文件编译时不丢失，但 resources 目录外的 *.properties 文件和 *.xml 文件会丢失。

解决方案：

• 如果需要把 src 目录下的除 .java 之外的文件包放到 target/classes 目录，作为输出的 jar 一部分。需要指定资源文件位置，将内容放到 标签中。

演示一：不指定配置文件的路径，在编译时会丢失

1、新建 maven_11 模块。

2、在 src/main/java/cn/myphoenix 路径下创建 2 个配置文件：hello.xml 和 larry.properties。

3、在 src/main/resources 路径下创建 2 个配置文件：jdbc.properties 和 SqlMapConfig.xml。

4、编译 maven_11 模块，查看配置文件情况。

结果如下图所示：

• src/main/java/cn/myphoenix 路径下的 2 个配置文件在编译后消失了。
• src/main/resources 路径下的 2 个配置文件依旧存在。

演示二：将配置文件的路径配置在 pom.xml 文件中，解决编译丢失问题

1、将两个路径下的配置文件都配置到 pom.xml 文件中。

<build>
    <resources>
        <!--src/main/java路径-->
        <resource>
            <directory>src/main/java</directory>
            <includes>
                <include>**/*xml</include>
                <include>**/*properties</include>
            </includes>
        </resource>
        <!--src/main/resources路径-->
        <resource>
            <directory>src/main/resources</directory>
            <includes>
                <include>**/*xml</include>
                <include>**/*properties</include>
            </includes>
        </resource>
    </resources>
</build>

2、clean 并重新编译 maven_11 模块，查看配置文件情况，成功。

附：pom 配置项解读

<build>
    <resources>
        <resource>
            <directory>src/main/resources</directory>
            <includes>
                <include>**/*xml</include>
                <include>**/*properties</include>
            </includes>
        </resource>
    </resources>
</build>

解释：

• ：这是 Maven 构建配置的根元素，包含了所有与构建相关的配置信息。
• ：用于定义项目中的资源文件。资源文件是指那些不需要编译但需要包含在最终构建输出中的文件，例如配置文件、静态文件等。
• ：表示一个资源文件集的配置。
• src/main/resources：指定资源文件的来源目录，这里是项目的 src/main/resources 目录。
• ：定义哪些文件应该被包含在构建过程中。 标签内可以包含多个 子标签，每个子标签指定一个文件匹配模式。
  • **/*xml：匹配所有以 .xml 结尾的文件，无论它们位于 src/main/resources 目录下的哪个子目录中。**/表示递归匹配所有子目录，因此即使文件位于深层子目录中，也会被包含进来。
  • **/*properties：匹配所有以 .properties 结尾的文件，无论它们位于 src/main/resources 目录下的哪个子目录中。

附：在 big-marketing-13119-lwh-app 的 pom.xml 中同样配置了配置文件的路径：

<resources>
    <resource>
        <directory>src/main/resources</directory>
        <filtering>true</filtering>
        <includes>
            <include>**/**</include>
        </includes>
    </resource>
</resources>

<testResources>
    <testResource>
        <directory>src/test/resources</directory>
        <filtering>true</filtering>
        <includes>
            <include>**/**</include>
        </includes>
    </testResource>
</testResources>