为何 Spring Boot 2.3.0 放弃Maven最终拥抱Gradle

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

Spring 的每一个项目都独立的项目组在开发运营，在用户最常使用的白盒部分（例如 API 设计）保持一致性，对于用户不可见的黑盒部分，各个项目组选择本身适合工具没有统一的约定。

例如： 项目构建工具。Spring Framework 自 2012 年的 3.2.0 起就使用 Gradle 构建，而一年后开始使用 Spring Boot，此后不久又开始使用 Spring Cloud，二者都基于 Maven。

项目	构建工具
Spring Framework	Gradle
Spring Boot	Maven
Spring Cloud	Maven

为何要切换

Spring Boot 团队考虑由 Maven 切换到 Gradle 的主要缘由为了减小构建项目所需的时间。在开发和测试过程当中，等待构建完成所花费的时间增长了修复错误和实现新功能所花费的时间。

为了解决这个问题，团队曾尝试利用 Maven 对并行构建的支持。因为 Spring Boot 构建的复杂性，特别是对 Invoker 插件的使用，尝试失败。经过将构建分为四个部分来解决 CI 问题。首先构建项目的主要核心，而后并行构建三个独立的部分。但 CI 的构建仍须要一个小时或更长时间。此外，因为针对的是模块化 CI 构建，所以并无使得开发人员本地构建效率有所改变。

Spring Boot 团队在其余利用 Gradle 做为构建工具的 Spring 项目中看到了 Gradle 的增量和并行构建以及在第三方项目中看到了 Gradle 的构建缓存的好处。但愿经过使用 Gradle 为 Spring Boot 构建得到相似的好处。

Gradle 具备很是灵活的构建模型，而且能够定义每一个任务的输入和输出及其相互依赖性。这种构建模型的好处是，它容许任务并行运行，同时也能够增量、缓存或彻底跳过。换句话说，Gradle 能够最小化的执行必要的 CI 任务。虽然可使用了 Gradle Enterprise 的 Maven 支持，咱们也能够享受构建缓存和跳过的好处。可是要充分享受这四个方面的好处，必须尝试切换到 Gradle。

如何切换

Gradle 配置过于灵活，致使它的构建比基于 Maven 构建更难以维护和理解。例如： 同一个构建结果，能够经过不一样的配置实现。若是切换到 Gradle，须要避免这种状况。从目前发布的四个 Spring Boot 2.3 里程碑版本，在核心团队或贡献者中，尚未发现任何重大的构建问题。

• Spring Boot 关键功能是约定优于配置，将这种方法应用于构建。避免在 build.gradle 文件中包含命令式逻辑，编写了几个能够在项目的中找到的小插件 buildSrc。。

虽然现有 Gradle 生态系统对 Spring Boot 构建几乎空白，须要从头经过编写不少通用的 gradle 插件来应用到 Spring Boot，但迁移到 Gradle 的提交从代码库中删除了近 9500 行。

切换结果

就减小项目构建时间而言，将构建迁移到 Gradle 无疑是成功的。如上所述，在 CI 和开发人员机器上，基于 Maven 的完整构建都须要一个小时或更长时间。而基于 Gradle 的平均成功构建时间为 9 分 22 秒，如如下截图所示：

若是对构建性能的更多细节感兴趣，能够在 Spring Boot 的公共Gradle Enterprise实例上得到更多数据。

除了提升性能外，对其余功能进行探索。例如，一段时间以来，进行许多不稳定的测试。因为这些缘由，构建失败的次数比预期要多，能够在 Tests 仪表板中看到这一点。使用 Gradle 分片测试来替代 CI 的通用测试方案，并帮组咱们了解是否已成功解决问题。

结论

CI 构建如今平均大约须要 20 分钟，比之前快 3-4 倍。
本地构建平均须要 2 分钟 30 秒，比之前快 20-30 倍。

https://spring.io/blog/2020/06/08/migrating-spring-boot-s-build-to-gradle

https://gitee.com/sxfad/gradle-scripts
项目推荐: Spring Cloud 、Spring Security OAuth2的RBAC权限管理系统 欢迎关注