Maven 的依赖

在上一节中，我们重点介绍了 Maven 的项目对象模型（POM），本节我们重点介绍另一个重要概念–依赖。我们会介绍什么是依赖，以及在我们平时的工作中的最佳实践。

1. 何为依赖？

依赖即为本项目对其他项目的引用，这里的其他项目可以是外部项目，也可以是内部项目。我们在开发项目的过程中，将其他项目作为依赖引用进来，最终在打包的过程中，依赖会和我们开发的项目打包到一起来运行。

在我们的项目没有使用 Maven 的时候，我们需要手动去管理我们的依赖，例如：添加依赖，删除依赖。在使用了 Maven 之后，我们可以在 pom.xml 文件里面看到我们所有的依赖，并且可以灵活的管理项目的依赖。

在上图中，我们可以清晰的看到我们项目目前所引用的依赖。

1.1 依赖的范围

Maven 在编译和运行以及执行测试用例的时候，分别会使用不同的 classpath。而 Maven 的依赖范围则是用来控制依赖与不同 classpath 关系的。

Maven 的依赖范围分为以下几种：

compile： 编译依赖范围。Maven 默认的依赖范围，该范围的依赖对编译，运行，测试不同的classpath 都有效。例如我们项目中的 spring-boot-starter；
test： 测试依赖范围。该依赖范围只对测试 classpath 有效，在编译项目或者运行项目的时候，是无法使用此类依赖的。例如我们项目中的 spring-boot-starter-test；
provided： 已提供依赖范围。该 Maven 依赖对于编译和测试的 classpath 有效，但是在运行时无效；
runtime： 运行时依赖范围。顾名思义，该依赖范围对测试和运行的 classpath 有效，但是在编译时无效；
system： 系统依赖范围。该依赖范围与 classpath 的关系与 provided 依赖范围是相同的。但是，在使用时需要谨慎注意，因为此类依赖大多数是与本机绑定的，而不是通过Maven仓库解析出来的，切换环境后，可能会导致依赖失效或者依赖错误。

2. 传递性依赖

目前我们的项目只引用了两个依赖，spring-boot-starter 和 spring-boot-starter-test，但是是这样子的吗？

为了能够更清晰的看到我们项目依赖的结构，我们可以在 IDEA 里面安装 Maven Helper 插件。

安装好之后，我们打开项目的 pom.xml 文件，可以看到在文件的下方多了一个 Dependency Analyzer按钮。打开之后，如下图。

从这里我们就可以看到，其实我们不只是引入了两个包，而是引入了很多个包，这是为什么呢？

答案是因为 Maven 的传递性依赖机制。

在我们这个项目中，我们引入了 spring-boot-starter 依赖，并且该依赖的范围是 compile，但是 spring-boot-starter 作为一个项目也有自己的依赖，在这其中的依赖范围为 compile 的依赖，则会自动转换成我们项目的依赖，例如 spring-boot 依赖，logback-core 依赖。

所以，有了 Maven 的传递性依赖机制之后，我们在使用一个依赖的时候，就不再需要考虑它又依赖了哪些，而是直接使用即可，其他的事情 Maven 会自动帮我们做完。

3. 最短路径原则

有了传递性依赖能够大大节省我们在管理依赖时候所耗费的精力。但是，如果传递性依赖出了问题我们应该如何解决呢？首先，我们应该知道的是传递性依赖是从哪条依赖路径引用进来的。

在我们的项目中就存在这样的例子。我们可以看到如下两条不同的引用路径：

1. spring-boot-starter --> spring-boot --> spring-aop --> spring-core

2. spring-boot-starter --> spring-core

这个时候，我们可以看到，两条路径最终引用的 spring-core 版本都是 5.2.5-RELEASE。但是如果引用的 spring-core 版本不同，Maven 会怎么做呢？

使用最短路径原则，路径2中的 spring-core 版本会本引用，这样就不会造成重复依赖的问题产生。

4. 最佳实践

4.1 排除依赖

传递性依赖可以帮助我们简化项目依赖的管理，但是同时也会带来其他的不必要的风险，例如：会隐式地引入一些依赖，这些依赖可能并不是我们希望引入的，或者这些隐式引入的依赖是 SNAPSHOT 版本的依赖。依赖的不稳定导致了我们项目的不稳定。

在我们的项目中，spring-boot-starter-test 依赖中排除了 junit-vintage-engine 依赖是由于我们使用的 springboot 版本是 2.2.6-RELEASE，对应的 Junit 版本是 5.x，但 junit-vintage-engine 依赖中包含了 4.x 版本的 Junit，此时我们就可以将该依赖排除。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
    <scope>test</scope>
    <exclusions>
        <exclusion>
            <groupId>org.junit.vintage</groupId>
            <artifactId>junit-vintage-engine</artifactId>
        </exclusion>
    </exclusions>
</dependency>

在 exclusions 标签中，可以有多个 exclusion 标签，用来排除不需要的依赖。

4.2 依赖归类

在我们实际的开发过程中，我们可能会需要整合很多第三方框架，在整合这些框架的时候，往往需要在 pom.xml 里面添加多个依赖来完成整合。而这些依赖往往是需要保持相同版本的，在升级框架的时候，都是要统一升级到一个相同的版本。

如下图，我们可以看到，在引入 dubbo 框架的时候，我们需要引入两个相关的依赖，而且版本号是相同的，这个时候，我们就可以把对应的版本号提取出来，放到 properties 标签里面，作为一个全局参数来使用。类似于 Java 语言中抽象的思想。

这时候，我们可以看到，如果在将来的某一天我们需要升级升级 dubbo 框架对应的版本，只需要修改 properties 中的版本号，就能将所有依赖的版本一起升级。

4.3 依赖优化

我们再回过头来看一下 Maven Helper 工具所展示的场景

我们在这个工具中可以看到我们项目现在引入的所有的依赖，可以看到哪些是我们用到的，哪些是没有用来的，依赖与依赖之间是否存在冲突。如果出现了上述情况，我们就可以通过删除或者依赖排除的方式来将我们不需要的依赖删除掉，从而使我们的项目更简洁。

5. 小结

本节中，我们介绍了 Maven 中的一个重要的概念–依赖，介绍了什么是依赖，以及依赖的几个特性，最后我们也总结了在平时的工作中常常会用到的依赖优化的方式，能够帮助我们更好的管理项目的依赖。