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

如果你使用Gradle而不是其他工具,为什么?


当前回答

Gradle可以用于许多目的——它是比Ant更好的瑞士军刀——但它特别专注于多项目构建。

首先,Gradle是一个依赖编程工具,这也意味着它是一个编程工具。使用Gradle,你可以在你的设置中执行任何随机任务,Gradle会确保所有声明的依赖都正确和及时地执行。您的代码可以以任何类型的布局(树形、平面、分散等)分布在许多目录中。

Gradle有两个不同的阶段:评估和执行。基本上,在评估期间,Gradle会在它应该查找的目录中查找和评估构建脚本。在执行期间,Gradle将执行在评估期间加载的任务,并考虑到任务的相互依赖性。

在这些依赖编程特性之上,Gradle通过与Apache Ivy集成增加了项目和JAR依赖特性。如你所知,Ivy是一个比Maven强大得多、不那么固执己见的依赖管理工具。

Gradle检测项目之间以及项目与jar之间的依赖关系。Gradle与Maven存储库(下载和上传)一起工作,比如iBiblio或你自己的存储库,但也支持你可能拥有的其他类型的存储库基础设施。

在多项目构建中,Gradle既能适应,又能适应构建的结构和架构。您不必像使用Maven那样根据构建工具调整结构或体系结构。

Gradle非常努力地不妨碍你,而Maven几乎从不这样做。惯例很好,灵活性也很好。Gradle提供了比Maven更多的特性,但最重要的是,在许多情况下,Gradle将为您提供从Maven过渡到Maven的轻松路径。

其他回答

我自己并没有因为愤怒而使用Gradle(到目前为止只是一个玩具项目)[作者的意思是他们到目前为止只在一个玩具项目中使用过Gradle,并不是说Gradle是一个玩具项目-见评论],但我想说的是,人们考虑使用它的原因是Ant和Maven的挫折。

在我的经验中,Ant通常是只写的(是的,我知道可以编写漂亮的模块化、优雅的构建,但事实是大多数人不这样做)。对于任何重要的项目来说,它都是令人费解的,并且需要非常小心地确保复杂的构建是真正可移植的。它的命令性可以导致在构建之间复制配置(尽管宏在这里可以提供帮助)。

Maven采取相反的方法,并期望您完全集成到Maven生命周期中。有经验的Ant用户会发现这一点尤其不和谐,因为Maven删除了您在Ant中拥有的许多自由。例如,有一个Sonatype博客列举了许多对Maven的批评和他们的回应。

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有望达到Ant和Maven之间的最佳点。它使用Ivy的方法进行依赖项解析。它允许约定优于配置,但也将Ant任务作为第一类公民。它还明智地允许您使用现有的Maven/Ivy存储库。

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更好的瑞士军刀——但它特别专注于多项目构建。

首先,Gradle是一个依赖编程工具,这也意味着它是一个编程工具。使用Gradle,你可以在你的设置中执行任何随机任务,Gradle会确保所有声明的依赖都正确和及时地执行。您的代码可以以任何类型的布局(树形、平面、分散等)分布在许多目录中。

Gradle有两个不同的阶段:评估和执行。基本上,在评估期间,Gradle会在它应该查找的目录中查找和评估构建脚本。在执行期间,Gradle将执行在评估期间加载的任务,并考虑到任务的相互依赖性。

在这些依赖编程特性之上,Gradle通过与Apache Ivy集成增加了项目和JAR依赖特性。如你所知,Ivy是一个比Maven强大得多、不那么固执己见的依赖管理工具。

Gradle检测项目之间以及项目与jar之间的依赖关系。Gradle与Maven存储库(下载和上传)一起工作,比如iBiblio或你自己的存储库,但也支持你可能拥有的其他类型的存储库基础设施。

在多项目构建中,Gradle既能适应,又能适应构建的结构和架构。您不必像使用Maven那样根据构建工具调整结构或体系结构。

Gradle非常努力地不妨碍你,而Maven几乎从不这样做。惯例很好,灵活性也很好。Gradle提供了比Maven更多的特性,但最重要的是,在许多情况下,Gradle将为您提供从Maven过渡到Maven的轻松路径。

We use Gradle and chose it over Maven and Ant. Ant gave us total flexibility, and Ivy gives better dependency management than Maven, but there isn't great support for multi-project builds. You end up doing a lot of coding to support multi-project builds. Also having some build-by-convention is nice and makes build scripts more concise. With Maven, it takes build by convention too far, and customizing your build process becomes a hack. Also, Maven promotes every project publishing an artifact. Sometimes you have a project split up into subprojects but you want all of the subprojects to be built and versioned together. Not really something Maven is designed for.

With Gradle you can have the flexibility of Ant and build by convention of Maven. For example, it is trivial to extend the conventional build lifecycle with your own task. And you aren't forced to use a convention if you don't want to. Groovy is much nicer to code than XML. In Gradle, you can define dependencies between projects on the local file system without the need to publish artifacts for each to a repository. Finally, Gradle uses Ivy, so it has excellent dependency management. The only real downside for me thus far is the lack of mature Eclipse integration, but the options for Maven aren't really much better.

这可能有点争议,但Gradle并没有隐藏它是一种成熟的编程语言的事实。

Ant + Ant -contrib本质上是一种图灵完整的编程语言,没有人真的想用它来编程。

Maven试图采取相反的方法,试图完全声明性,并强迫您在需要逻辑时编写和编译插件。它还强加了一个完全不灵活的项目模型。Gradle结合了所有这些工具的优点:

它遵循约定优于配置(类似Maven),但仅限于您想要的程度 它允许您像在Ant中那样编写灵活的自定义任务 它提供了优于Ant和Maven的多模块项目支持 它有一个DSL,使80%的事情变得简单,20%的事情成为可能(不像其他构建工具使80%的事情变得简单,10%的事情成为可能,而10%的事情实际上是不可能的)。

Gradle是我使用过的最具可配置性和灵活性的构建工具。它需要一些前期投资来学习DSL和诸如配置之类的概念,但如果你需要一个没有废话且完全可配置的JVM构建工具,那么它是很难被取代的。

我在一定程度上同意Ed Staub的观点。与maven相比,Gradle无疑更强大,从长远来看也提供了更多的灵活性。

在执行从maven到gradle的评估之后,我们决定在两个问题上坚持使用maven本身 我们遇到gradle(速度比maven慢,代理不工作)。