从停用Maven，拥抱Gradle开始，学习SpringBoot

前言

SpringBoot2.3一系列版本发布以来，有了很多的特性，比如优雅的关机。众多新的特性，代表作为公认的开源家族Spring来说，一直都在进步。那么我们就需要从变化中，汲取其中的养分和思考变化的原因。好了，回归今天的主题。一直关注提交者大佬的Twitter，近来大佬发的一个消息，比较震撼，也是一种信号。

大意为：在Spring Boot 2.3中，我们将构建从Maven迁移到了Gradle。如果您对我们进行更改的原因和方式感兴趣，我刚刚发布了一篇博客文章，其中包含一些详细信息：https://spring.io/blog/2020/06/08/migrating-spring-boot- s逐步构建……。现在，平均而言，CI构建速度提高了3到4倍，本地构建速度提高了20到30倍。正如大佬的评论区的疑问一样，我也有类似的疑问。

那么，就详细的看了下，对应的文章 https://spring.io/blog/2020/06/08/migrating-spring-boot-s-build-to-gradle 文章对疑问做了很好的诠释。

实实在在的变化

确实，在2.3.0.M1中对Spring Boot进行了相当重大的更改。这是使用Gradle而非Maven构建的项目的第一个版本。

为何切换

Spring Boot团队考虑改用Gradle的主要原因是为了减少构建项目所需的时间。在进行和测试更改时，反应链过长，等待构建完成所花费的时间增加了修复错误和实现新功能所花费的时间。在其他Spring项目中看到了Gradle的增量和并行构建的好处，在第三方项目中看到了Gradle的构建缓存的好处。希望可以在Spring Boot的构建中获得类似的好处。

过去，虽然曾尝试利用Maven对并行构建的支持。由于Spring Boot构建的复杂性，特别是对Invoker插件的使用，尝试失败。

Gradle具有构建结构的广泛模型，了解每个任务的输入和输出及其相互依赖性。这种建模的承诺是，它允许任务并行运行，同时也可以增量，缓存或完全避免。换句话说，Gradle旨在最小化构建任何给定更改并并行执行必需的工作所需的工作量。因此，需要使用到Gradle的优点，是切换的一大原因。

好处在哪

就减少项目的构建时间而言，将构建迁移到Gradle无疑是成功的。如上所述，在CI和开发人员自己的计算机上，基于Maven的完整构建都需要一个小时或更长时间。经过官方测试，Gradle的平均成功构建时间为9分22秒，如以下屏幕截图所示：

从图中，我们可以看到如此明显的提升。

如何切换

按照文章理解来，如下：

长久来，对Gradle的一种批评是，它导致的构建比基于Maven的构建更难以维护和理解。Gradle的灵活性使事情可以以不同的方式完成，即使是同一版本中的各个模块也是如此。如果切换成功，就需要避免这种情况。已经发布了四个Spring Boot 2.3里程碑，其候选发布版以及与Gradle一起发布的最终版本，看来已经成功了。在核心团队或其他任何贡献者中，还没有发现任何重大的构建问题。

Spring Boot的一个关键功能是约定优于配置，也将这种方法应用于构建。按照避免在build.gradle文件中包含命令式逻辑的建议，编写了几个可以在项目的buildSrc中找到的小插件。例如，有一个适用于每个Spring Boot启动器模块的启动器插件，以确保它们的配置，构建和发布都一致我们还有一个约定俗成的插件，可以对正在应用的其他插件做出反应，并配置诸如源代码编码，使用JUnit Platform以及使用-parameters进行编译等功能。

这种方法导致build.gradle文件几乎完全是声明性的。即使编写了许多插件来应用约定并填补Gradle生态系统中的空白，但迁移到Gradle的提交从代码库中删除了近9500行。

对于切换的过程，我们可以大致了解下，可以追溯历史，看到从2.3开始版本，开始使用Gradle构建。

总结思考

虽然CI构建效率大大相比Maven构建大大提升，也许会有小伙伴质疑，Spring Boot 迁移到了 Gradle，会不会对公司现有的 Maven 项目或者后续的版本升级造成影响呢？答案是否定的。

Gradle 肯定是未来的趋势，但也不一定非得迁移至 Gradle，只有适合自己的才是最好的，毕竟现在 Maven 和 Gradle 都是主流，而且Maven 更占有市场，很多主流开源项目都是以 Maven 依赖来作为示例演示的。

但是，按照技术人的思维来看，我们也需要去了解，学习Gradle的构建过程。在未来一刻，估计最后还是要拥抱Gradle。