为什么使用Gradle而不是Ant或Maven？ [英] Why use Gradle instead of Ant or Maven?

问题描述

另一个针对Java的构建工具真的让我感到满意吗？

如果您使用Gradle而不是其他工具，为什么？

解决方案

我不会在自己的愤怒中使用 Gradle （目前为止只是一个玩具项目）[作者意味着他们迄今为止只在一个玩具项目上使用了Gradle，而不是Gradle是一个玩具项目 - 参见评论] ，但我会说原因人们会考虑使用它会是因为Ant和Maven的挫折。

根据我的经验，Ant经常是只写的（是的，我知道可以写< a href =http://onjava.com/pub/a/onjava/2003/12/17/ant_bestpractices.Html =noreferrer>精美的模块化，优雅的构建 s，但事实是最人们不）。对于任何不平凡的项目来说，它都会变得精神恍惚，并且非常谨慎地确保复杂的构建是真正可移植的。它的命令性质可以导致在构建之间复制配置（尽管宏可以在这里帮助）。

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，尽管在我看来，如果你不仅仅为未知的问题交易已知问题还有待观察。虽然布丁的证明是在吃东西，但我会保留判断力，直到产品稍微成熟一些，并且其他人已经解决了任何扭结（出于某种原因，他们称它为流血的边缘）。尽管如此，我仍然会在我的玩具项目中使用它，总是很好的了解这些选项。

What does another build tool targeted at Java really get me?

If you use Gradle over another tool, why?

解决方案

I don't use Gradle in anger myself (just a toy project so far) [author means they have used Gradle on only a toy project so far, not that Gradle is a toy project - see comments], but I'd say that the reasons one would consider using it would be because of the frustrations of Ant and Maven.

In my experience Ant is often write-only (yes I know it is possible to write beautifully modular, elegant builds, but the fact is most people don't). For any non-trivial projects it becomes mind-bending, and takes great care to ensure that complex builds are truly portable. Its imperative nature can lead to replication of configuration between builds (though macros can help here).

Maven takes the opposite approach and expects you to completely integrate with the Maven lifecycle. Experienced Ant users find this particularly jarring as Maven removes many of the freedoms you have in Ant. For example there's a Sonatype blog that enumerates many of the Maven criticisms and their responses.

The Maven plugin mechanism allows for very powerful build configurations, and the inheritance model means you can define a small set of parent POMs encapsulating your build configurations for the whole enterprise and individual projects can inherit those configurations, leaving them lightweight. Maven configuration is very verbose (though Maven 3 promises to address this), and if you want to do anything that is "not the Maven way" you have to write a plugin or use the hacky Ant integration. Note I happen to like writing Maven plugins but appreciate that many will object to the effort involved.

Gradle promises to hit the sweet spot between Ant and Maven. It uses Ivy's approach for dependency resolution. It allows for convention over configuration but also includes Ant tasks as first class citizens. It also wisely allows you to use existing Maven/Ivy repositories.

So if you've hit and got stuck with any of the Ant/Maven pain points, it is probably worth trying Gradle out, though in my opinion it remains to be seen if you wouldn't just be trading known problems for unknown ones. The proof of the pudding is in the eating though so I would reserve judgment until the product is a little more mature and others have ironed out any kinks (they call it bleeding edge for a reason). I'll still be using it in my toy projects though, It's always good to be aware of the options.

这篇关于为什么使用Gradle而不是Ant或Maven？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！