为什么Spring官方推荐应用开发使用Gradle？Gradle更优秀是未来

2023-02-28

系统 boot 插件

Spring官方曾发布一篇文章《Spring/SpringBoot编译工具从Maven迁移到了Gradle》，说明为什么Spring（2012年）和SpringBoot（2020）的源码构建使用Gradle。主要迁移的原因还是因为Gradle的构建速度远远优于Maven。近期，生成Sprin

Spring官方曾发布一篇文章《Spring/Spring Boot编译工具从Maven迁移到了Gradle》，说明为什么Spring（2012年）和Spring Boot（2020）的源码构建使用Gradle。主要迁移的原因还是因为Gradle的构建速度远远优于Maven。

近期，生成Spring Boot应用项目的网站Spring Initializr(start.spring.io)，也开始使用Gradle作为默认的构建工具。

这给习惯于使用Maven的开发者带来了不少的困惑和不赞同，有没有去做这个调整吗？

Spring官方在Spring Initializr的github的issue上给出了答案，我带大家一起来阅读下这个issue（https://github.com/spring-io/start.spring.io/issues/1012）。

Andy Wilkinson（Spring Boot主要研发）

start.spring.io团队认为，对于今天开始一个新项目的任何人来说，Gradle是更好用的构建系统。对于基于Spring Boot 3.0的应用程序尤其如此，在这些应用程序中，开发人员使用Gradle进行AOT（Spring 6和Spring Boot 3.0颠覆性的新特性）处理的体验要好得多。我们希望推动社区使用Gradle，同时确保Maven对于那些喜欢它的人来说只需点击一下即可。

Gradle是更好用的构建系统

提问者

为什么你认为Gradle是更好的构建系统？在我看来，Maven更易于使用且不易混淆，尤其是对于初学者而言。

为什么Gradle是更好的构建系统

Cédric Champeau（来自Oracle Labs，在Micronaut团队工作）

为什么你认为Gradle是更好的构建系统？

为了能够说什么是“更好”，我们需要获得更好的资格。我不会说Gradle绝对更好，但它确实在很多方面击败了Maven。当我们想要比较时，我们应该尽量做到真实。

在我看来，Maven更易于使用且不易混淆，尤其是对于初学者而言。

我不同意这个观点，并用几个方面来说明Gradle在客观上比Maven更好。

首先，我想大家都同意Maven比Gradle使用更广泛。

因此，有一个习惯偏差，即你知道Maven这个工具，所以你可以“更容易”地使用它：你知道这些命令，你更习惯阅读POM文件等。

第二个偏见是Maven已经存在多年，因此许多流程都是围绕Maven细节构建的。

例如，人们很难停止调用mvn clean install，这并不奇怪。这是使用Maven工具的结果，多年来，如果你在install前没有进行clean，Maven就一直不可靠。当然，你会发现有人说“你不再需要再clean了”，但这并不完全正确。

Gradle就没有这样的问题，因为它是一个完全增量构建系统。

在Gradle中，一切都声明了输入和输出，因此无论何时执行命令，Gradle都知道要重新执行或不执行什么，包括在需要时删除陈旧文件。

Gradle还为Java（和Groovy）提供增量编译，以及避免编译（如果下游项目没有改变，则避免重新构建）。

一般来说，Gradle比Maven快得多，而且Gradle构建缓存让事情变得更加有趣。

Gradle还解决了长期存在的问题，例如类路径污染。

在构建结构方面，现代Gradle构建的设计明显优于旧版本。Gradle通过“偏爱组合而不是继承”来修复臭名昭著的Maven单继承模型。

Gradle还可以对其他插件的应用做出反应，使其具有高度的可组合性和可重用性。我甚至没有提到可以测试你的构建逻辑本身这一事实，这是一个巨大的胜利。让我用Micronaut如何使用约定插件来说明Micronaut中的每个项目都配置相同，而没有认知开销：一个项目说明它是什么（BOM），而不是如何构建。

Gradle还高度关注开发人员的生产力。例如，持续监视源代码变化并立即重新执行任务（编译、测试）的连续模式改变了游戏规则。类似地，复合构建在多个库的集成方面改变了游戏规则，与旧的但是不错的SNAPSHOT相比。

在依赖管理方面，Gradle也比Maven提供的领先多年（依赖约束、依赖验证、丰富的版本约束、模块替换、变体感知解决...）,可以解决现实世界的问题，但也支持更复杂的生态系统，如Android或Kotlin MPP。

Gradle可以更好的另一个例子是插件作者。正如Andy所说，作为插件作者，Gradle让我们的生活变得更加轻松，因为它没有Maven生命周期的限制。对于像原生构建这样的复杂主题，它需要的东西明显偏离主要方法，例如因为我们需要在JVM模式下运行测试，然后运行原生构建，然后在原生模式下运行测试，并使用先前的输出测试等...Gradle模型明显更适合于此并且不会强迫我们插件作者编写复杂的代码到达Maven的内部来完成这份工作。Gradle更容易。

我知道改变会有很多阻力，但恕我直言，Gradle是未来。我也永远不会说学习曲线是平坦的：它不是，特别是对于那些已经深入Maven多年的人来说：Gradle的工作方式根本不同，但一旦你习惯了，就很难再回来了。当然，你会发现人们从Gradle回滚到Maven，这是不可避免的。

长话短说：你会发现人们说Maven比Gradle更好。如果你这样做，请定义“更好”，因为我可以客观地找到Gradle更好的许多地方。我个人可以找到Maven“更好”的地方。例如，Maven更容易传递属性以覆盖构建的某些属性。然而，这通常与你应该如何设计Gradle构建的“错误心态”有关（例如，人们习惯使用Maven配置文件，而Gradle完全不需要它们）。或者，与Gradle相比，对插件作者来说MavenAPI的稳定性，Gradle每年都在快速发展并且破坏一次（对于每个主要版本）。这对插件作者来说是一个痛点，但对用户来说却不是，因为用户通常不会受此困扰。

我不会继续说下去，因为有很多理由让人更喜欢Gradle而不是Maven。最后你还是选择留在Maven，我不会！