为什么使用Gradle代替Ant或Maven？

Question

另一个针对Java的构建工具到底能给我带来什么？

如果您在其他工具上使用Gradle，为什么？

Answer 1

我不会用Gradle来激怒自己（到目前为止只是一个玩具项目）
[作者表示，到目前为止，他们仅在一个玩具项目上使用了Gradle，而不是Gradle是一个玩具项目-请参阅评论]
，但我要说的是人们之所以考虑使用它的原因是因为Ant和Maven的挫败感。

以我的经验，Ant通常是只写的（是的，我知道可以编写漂亮的模块化，优雅的build，但事实是大多数人不会写）。对于任何不重要的项目，它都会变得弯曲，并会格外小心，以确保复杂的构建真正可移植。它的命令性性质可以导致在构建之间复制配置（尽管宏可以在此提供帮助）。

Maven采用相反的方法，并希望您与Maven生命周期完全集成。有经验的Ant用户会发现这特别令人讨厌，因为Maven消除了您在Ant中拥有的许多自由。例如，有一个Sonatype博客，列举了许多Maven批评及其回应。

Maven插件机制允许非常强大的构建配置，并且继承模型意味着您可以定义一小套父POM，将您的构建配置封装为整个企业，而单个项目可以继承这些配置，从而使其轻量化。Maven配置非常冗长（尽管Maven
3承诺会解决此问题），并且如果您想做“非Maven方式”的任何事情，则必须编写插件或使用hacky的Ant集成。请注意，我碰巧喜欢编写Maven插件，但感谢许多人会反对所涉及的工作。

Gradle承诺会在Ant和Maven之间达到最佳位置。它使用Ivy的方法来解决依赖项。它允许在配置上进行约定，但还包括作为头等公民的Ant任务。它还明智地允许您使用现有的Maven
/ Ivy存储库。

因此，如果您遇到了任何麻烦，并且陷入了Ant /Maven的任何痛点，则值得尝试Gradle，尽管在我看来，是否您不只是将已知问题换成未知问题，还有待观察。布丁的证据是在饮食中，所以我会保留判断，直到产品更成熟，其他人消除了任何扭结（由于某种原因，他们称其为流血边缘）。不过，我仍将在玩具项目中使用它，意识到这些选择总是很高兴的。