我们在2.3.0.M1中对Spring Boot进行了相当重大的更改。这是使用Gradle而非Maven构建的项目的第一个版本。
Spring Boot团队考虑切换到Gradle的主要原因是为了减少构建项目所需的时间。在进行和测试更改时，我们对反馈循环的长度感到沮丧。等待构建完成所花费的时间增加了修复错误和实现新功能所花费的时间。我们已经在其他Spring项目中看到了Gradle的增量和并行构建以及在第三方项目中看到了Gradle的构建缓存的好处。我们希望我们可以在Spring Boot的构建中获得类似的好处。
过去，我们曾尝试利用Maven对并行构建的支持。由于Spring Boot构建的复杂性，特别是对Invoker插件的使用，我们的尝试失败了。我们通过将构建分为四个部分来解决CI问题。首先构建项目的主要核心，然后并行构建三个独立的部分。这种安排有所帮助，但CI的构建仍需要一个小时或更长时间。此外，由于拆分结构特定于CI构建，因此它并没有使开发人员的本地构建更快。
Gradle具有构建结构的广泛模型，了解每个任务的输入和输出及其相互依赖性。这种建模的承诺是，它允许任务并行运行，同时也可以增量，缓存或两者完全避免。换句话说，Gradle旨在最小化构建任何给定更改并并行执行必需的工作所需的工作量。使用Maven可能也可以并行构建。如果使用了Gradle Enterprise的Maven支持，我们也可以享受构建缓存和不使用缓存的好处。但是，要充分享受这四个方面的好处，我们认为我们必须尝试切换到Gradle。
我们看到的对Gradle的一种批评是，它导致的构建比基于Maven的构建更难以维护和理解。Gradle的灵活性使事情可以用微妙的不同方式完成，即使是同一构建中的各个模块也是如此。
我想借此机会感谢Gradle团队在迁移过程中提供的帮助，并慷慨地向我们提供了Gradle Enterprise许可以与我们的开源项目一起使用。我们已经在Spring Framework，Spring Security和Spring Boot中使用了它，其他团队计划开始在基于Gradle和Maven的构建中使用它。
我还要感谢我们正在使用的各种第三方插件的维护者。他们提出了建议的更改，并合并了拉取请求，以改善对增量构建和缓存的支持。没有它们，我们将无法实现我们所看到的构建时间的减少。
如果您正在考虑从Maven迁移到Gradle，我希望多了解一些Spring Boot团队的经验是有用的。如果您是快乐的Maven用户，请继续使用并支持对您有效的工具。