停止关于Gradle的战斗

停止F的约#Spring ＆ #Hibernate迁移到#Gradle 。 在我之后重复：“我的项目没有相同的要求” #Maven

-尼古拉斯·弗兰克尔（Nicolas Frankel）（我相信@Home很长时间了）（@ nicolas_frankel） 2013年7月16日

这是我本周的仇恨，我对其中的每个角色都负全部责任。

虽然这看起来像是一个巨魔，但Twitter并不是真正进行辩论并进行事实辩论的地方，所以这里是后续活动。

在进入成熟的修辞模式之前，我首先要说的是，尽管人们普遍相信，但我对闪亮的新事物持开放态度。 例如，尽管是Vaadin的信奉者-这是一种有状态的服务器端技术，但我对AngularJS也很感兴趣-这与之完全相反。 我也赞成使用TestNG而不是JUnit，等等。 我什至参加了在Devoxx France举行的Gradle会议！ 所以，请听到我的论点，然后再考虑一下。

到目前为止，我只听到两个赞成Gradle的论点：

1. 它很灵活（暗示不是Maven）
2. Spring和Hibernate使用它

两者都是事实，让我们详细研究它们中的每一个，以检查为什么它们不是参数。

Gradle很灵活

不可否认Gradle是灵活的：我的意思是，它是具有构建DSL的Groovy。 让我们走得更远：如何实现灵活性？ 我的看法是，它来自以下方面。

• 提供非常细粒度-几乎是原子的操作：编译，复制，移动，打包等。
• 允许定义这些操作的列表-任务：打包JAR意味着将类和资源文件复制到专用文件夹中并进行压缩
• 启用它们之间的依赖关系：打包依赖于编译

如果仔细观察，我说的内容当然可以应用于Gradle，也可以应用于Ant！ 是的，两者都在相同的粒度级别上运行。

现在的问题在于，Gradle的支持者告诉Gradle柔韧性，好像柔韧性是一种理想的品质。 让我说：灵活性不是构建工具的品质。 我什至会说这是一个很大的劣势。 这与将断胳膊伸入石膏中相同。 这是绝对缺乏灵活性（至少可以说），但这是为了您自己的利益。 强制转换会阻止您以痛苦的方式前进，就像不灵活的​​构建工具（例如Maven）会使奇怪的事情变得昂贵一样。

如果由于您的特定上下文需要一遍又一遍地做某事，那是因为经常性的要求。 在Maven中，您将创建一个插件来解决它并完成此工作。 如果是一次性的要求，那可能就不是一个要求，而是一个怪癖。 重新考虑您的操作方式，这绝对是一种腥味。

Spring和Hibernate都使用Gradle

那真的让我发笑：因为某些框架选择了构建，所以我们应该只使用它们的构建，没有问任何问题？ 您真的检查过为什么他们首先迁移了吗？

我什至不会看Hibernate案例 ，因为它使我无休止地阅读诸如“我个人讨厌……”或“……定义构建和目录的方式对我来说似乎有意义”之类的论点。 这不是更改构建工具的充分理由（在后一种情况下，是真实显示虚假的自我）。

对于Spring来说，好吧... Groovy只是他们的战略之路，已经存在多年了。 SpringSource Tools Suite完全支持Groovy，所以我想使用Gradle是一种将Groovy的爱传播到全世界的方式。 我听说过的另一个技术原因是Spring必须与不同的Java版本兼容，而Maven无法解决这个问题。 我懒得自己检查一下，但是即使那是真的，也只有很少的机会适用于您当前的项目。

Gradlew是一项很酷的功能

我所知道的当前我唯一缺少的功能-绝对会很想拥有的功能是，一劳永逸地设置构建引擎版本，如果需要的话，可以从现在开始运行10年。 令人惊讶的是，许多软件产品进入了多年的首次维护周期，并且从源头开始出现亏损。 相信我，这发生在我身上（在VB环境中），但是我有幸拥有一个才华横溢的人，但不幸的是我无法依靠。

用Gradle的话来说，这种功能是通过Gradle Wrapper来实现的 。 使用该工具可以下载构建引擎本身，因此可以将其放入版本控制中。 不幸的是，没有人提出这一观点🙂尽管这不足以让我想迁移。

注意：在撰写本文时，我只是搜索了该功能到Maven的端口，然后找到了maven-wrapper 。 任何反馈？

结语

TL; DR：

• Gradle只是Groovy的Ant，而不是XML
• 您的上下文（可能）与使用Gradle的框架的上下文不同

这两点都只有一个合乎逻辑的结论：没有真正的理由使用Gradle，停止它的开发，然后再回头开发下一个Google Search，这样做有更多的价值！

翻译自: https://blog.frankel.ch/stop-the-f-about-gradle/