如果您正在考虑从Maven迁移到Gradle，希望多了解SpringBoot团队的经验对您有所帮助。如果您是一名快乐的Maven用户，请继续使用和支持适合您的工具。原文地址：https://spring.io/blog/2020/06/08/migrating-spring-boot-s-build-to-gradle在2.3.0.M1我们对SpringBoot做了比较大的改动。这是使用Gradle而不是Maven构建的项目的第一个版本。关于迁移的Twitter线程已经有很多人问我们为什么要转换以及我们看到的好处（如果有的话）。这篇博文旨在回答这些问题。Spring产品套件中的每个项目都以相当自主的方式运行。我们力求在用户最明显的地方保持一致性——例如API设计，但选择最能满足项目需求的工具却不太明显。一个例子是构建系统。对构建系统的更改会影响那些为项目做出贡献的人，但如果我们做对了，它不会对用户产生影响。这导致混合了基于Maven和Gradle的构建。例如，SpringFramework从2012年的3.2.0.M1开始使用Gradle构建；一年后SpringBoot诞生，紧接着SpringCloud开始，当时都使用基于Maven的构建。与SpringBoot不同，SpringCloud目前没有转换的计划，因为Maven满足了他们的需求。简而言之，如果您只能从这篇博文中学到一件事，那就是您应该选择最能满足项目需求的工具。我们为什么要切换？SpringBoot团队考虑改用Gradle的主要原因是为了减少构建项目所需的时间。在进行测试修改时，我们对反馈循环的长度感到沮丧。等待构建完成所花费的时间增加了修复错误和实现新功能所花费的时间。我们已经在其他Spring项目中看到了Gradle的增量和并行构建以及Gradle构建缓存在第三方项目中的好处。我们希望我们可以在我们的SpringBoot构建中获得类似的好处。我们过去曾尝试利用Maven对并行构建的支持。由于SpringBoot构建的复杂性，尤其是Invoker插件的使用，我们的尝试失败了。我们通过在CI（持续集成）上将构建分成四个部分来解决这个问题。首先建造项目的主要核心，然后并行建造三个独立的部分。这种安排有所帮助，但CI构建任务仍然需要一个小时或更长时间。此外，由于拆分结构特定于CI构建，因此它不会使开发人员的本地构建更快。Gradle具有广泛的构建结构模型，了解每个任务的输入和输出及其相互依赖性。这种建模的承诺是它允许任务并行运行，同时也可以增量、缓存或完全避免。换句话说，Gradle旨在最大限度地减少构建任何给定更改所需的工作量，并行执行必要的工作。如果我们坚持并广泛重构SpringBoot的构建，则可能会使用Maven并行构建。而且，如果我们使用GradleEnterprise的Maven支持，我们还可以享受构建缓存和避免的好处。然而，为了充分享受这四者的好处，我们觉得我们必须尝试切换到Gradle。我们如何切换？我们看到的对Gradle的一种批评是，它导致构建比基于Maven的构建更难维护和理解。Gradle的灵活性允许任务以细微不同的方式完成，即使是在同一个构建中的模块之间。如果要成功移交，我们需要避免这种情况。我们已经发布了四个SpringBoot2.3里程碑（候选发布版和最终版Gradle），看起来我们一拍即合。核心团队和任何其他贡献者都没有发现任何重大构建问题。SpringBoot的一个关键特性是“约定优于配置”，我们也将这种方法应用于构建。按照“避免在build.gradle文件中使用命令式逻辑”的建议，我们编写了几个小插件，可以在项目的[buildSrc](https://github.com/spring-projects/spring-boot/tree/d4c7315369e7e9dce6eb1c77e5f23d1e670247c8/构建源）。例如，我们有一个应用于每个SpringBoot启动模块的启动插件，确保它们的配置、构建和发布都是一致的。我们还有一个约定插件，它对正在应用的其他插件做出反应，并配置源代码编码、JUnit平台的使用以及使用“-parameters”进行编译等。这种方法生成的build.gradle文件几乎完全是声明性的。尽管我们编写了许多插件来应用我们的约定并填补Gradle生态系统中的空白，但迁移到Gradle的承诺从代码库中删除了近9500行。转换有好处吗？就减少项目的构建时间而言，将构建迁移到Gradle无疑是成功的。如上所述，在CI和开发人员自己的机器上，一个完整的基于Maven的构建需要一个小时或更长时间。在过去的四个星期里，使用Gradle的平均成功构建时间为9分22秒，如下面的屏幕截图所示：我们从JDK8CI构建发布快照。专注于这些，它在过去4周内成功了183次，平均构建时间为19分37秒。查看成功的本地构建，我们可以看到：过去4周内有273次成功构建平均构建时间2分钟30秒Gradle吸引我们的另一个好处是我享受为Testcontainers做贡献的体验。我们希望SpringBoot贡献者能够尽快克隆和构建项目。由于远程构建缓存，构建可以在3分钟内完成，包括下载大量依赖项所花费的时间。如果您对有关构建性能的更多详细信息感兴趣，可以在我们的公共GradleEnterprise实例上获得更多数据。除了性能改进之外，我们还开始查看其他一些可用数据。例如，我们已经意识到我们有一些不稳定的测试。由于它们，构建失败的频率比我们预期的要高，我们现在可以在测试仪表板中看到这一点。我们已经开始使用Gradle的脆弱测试缓解来识别CI上发生的任何脆弱测试，以帮助我们了解我们是否已成功修复或解决问题。结论我们对迁移的进展和构建时间的减少感到非常满意。CI构建现在平均需要大约20分钟，比以前快3-4倍。本地构建平均耗时2分30秒，比之前快20-30倍。我想借此机会感谢Gradle团队在迁移过程中提供的帮助，并慷慨地为我们提供GradleEnterprise许可证以用于我们的开源项目。我们已经将它与SpringFramework、SpringSecurity和SpringBoot一起使用，其他团队计划开始将它用于Gradle和基于Maven的构建。我还要感谢我们使用的各种3rd方插件的维护者。他们提出了建议的更改并合并了拉取请求，以改进对增量构建和缓存的支持。没有他们，我们将无法实现我们所看到的构建时间的减少。如果你正在考虑从Maven迁移到Gradle，希望多了解SpringBoot团队的经验对你有所帮助。如果您是一名快乐的Maven用户，请继续使用和支持适合您的工具。文章来自：热爱科学的卫斯理，如需转载本文，请即日联系热爱科学的卫斯理头条号。
