[next] [prev] [prev-tail] [tail] [up]

Chapter 5
Overview

5.1 Features

Here is a list of some of Gradle’s features.

Language for Dependency Based Programming
This is the core of Gradle. Most build tools do offer such a thing. You can create tasks, create dependencies between them and those tasks get executed only once and in the right order. Yet compared to Ant1 Gradle’s task offer a rich API and can be any kind of object. Gradle’s tasks support multi-project builds. There is much more to say about tasks later on.
Flexible Build By Convention
Gradle offers you build-by-convention on top of its core layer. It is the same idea as implemented by Maven. But Gradle’s build-by-convention approach is highly configurable and flexible. And you don’t have to use it, if you need utmost flexibility. You can enable/disable it on a per project basis in a multi-project build.
Ant Tasks
Ant tasks are first class citizens. Using Ant tasks from Gradle is as convenient and more powerful than using Ant tasks from a build.xml file.
Configure By DAG
Gradle has a distinct configuration and execution phase. Thus we can offer you special hooks. You can add configuration to your build, based on the complete execution graph of tasks, before any task is executed.
Easy Ivy
Our dependency management is based on Apache Ivy, the most advanced and powerful dependency management in the Java world. We have Ivy integrated in our build-by-convention framework. It is ready to go out-of-the-box. Ivy is mostly used via its Ant tasks but it also provides an API. Gradle integrates deeply with Ivy via this API. Gradle has its own dependency DSL on top of Ivy. This DSL introduces a couple of features not provided by Ivy itself.
Client Modules
We think dependency management is important to any project. Client Modules provide this, without the need of remote repositories and ivy.xml or pom.xml files. For example you can just put your jars into svn and yet enjoy complete transitive dependency management. Gradle also support fully Ivy or Maven repository infrastructures based on ivy.xml or pom.xml files and remote repositories.
Cross Project Configuration
Enjoy how easy and yet how extremely powerful the handling of multi-project builds can be. Ivy introduces Configuration Injection to make this possible.
Distinct Dependency Hierarchies
We allow you to model the project relationships in a multi-project build as they really are for your problem domain. Gradle follows your layout not vice versa.
Partial Builds
With Maven multi-project builds only work if executed from the root project and thus requiring a complete build. If you build from a subproject, only the subproject is build, not the projects the subproject depends on. Gradle offers partial builds. The subproject is build plus the projects it depends on. This is very convenient for larger builds.
Internal Groovy DSL
Gradle’s build scripts are written in Groovy, not XML. This offers many advantages to XML: Rich interaction with existing libraries, ease of use, more power and a slower learning curve are some of them.
The Gradle Wrapper
The Gradle Wrapper allows you to execute Gradle builds on machines where Gradle is not installed. For example continuous integration servers or machines of users which want to build your open source project.

Gradle scales very well. It significantly increases your productivity, from rather simple single project builds up to huge enterprise multi-project builds.

Gradle is build by Gradle. From a build perspective Gradle is a simple project. But achieving the high degree of automation we have, would have been very hard (and expensive) to achieve with Ant or Maven.

5.2 Why Groovy?

We think the advantages of an internal DSL (based on a dynamic language) over XML are tremendous in case of build scripts. There are a couple of dynamic languages out there. Why Groovy? The answer lies in the context Gradle is operating in. Although Gradle is a general purpose build tool at its core, its main focus are Java projects.2 In such projects obviously the team members know Java. One problem we see with Ant3 and Maven is, that it involves a lot of knowledge only available to the build master. Such builds are very hard to comprehend, let alone to modify by a person not deeply involved with those tools. We think a build should be as transparent as possible to all team members.

You might argue why not using Java then as the language for build scripts. We think this is a valid question. It would have the highest transparency for your team and the lowest learning curve. But due to limitations of Java such a build language would not be as nice, expressive and powerful as it could be.4 Languages like Python, Groovy or Ruby do a much better Job here. We have chosen Groovy as it offers by far the highest transparency for Java people. Its base syntax is the same as Java’s as well as its type system, its package structure other things. Groovy builds a lot on top of that. But on a common ground with Java.

For Java teams which share also Python or Ruby knowledge or are happy to learn it the above arguments don’t apply. In the near future Gradle wants to give you a choice between different languages for your build scripts. For Jython or JRuby this should be easy to implement. If members of those communities are interested in joining this effort, this is very much appreciated.

5.3 Missing Features

Here a list of features you might expect but are not available yet:

[next] [prev] [prev-tail] [front] [up]