Multi-project builds
Gradle's support for multi-project build is outstanding. Project dependencies are first class
citizens. 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.
Gradle provides partial builds. If you build a single subproject Gradle takes care of building
all the subprojects that subproject depends on. You can also choose to rebuild the
subprojects that depend on a particular subproject. Together with incremental builds this is a
big time saver for larger builds.
Many ways to manage your dependencies
Different teams prefer different ways to manage their external dependencies. Gradle
provides convenient support for any strategy. From transitive dependency management with
remote maven and ivy repositories to jars or dirs on the local file system.
Gradle is the first build integration tool
Ant tasks are first class citizens. Even more interesting, Ant projects are first class citizens
as well. Gradle provides a deep import for any Ant project, turning Ant targets into native
Gradle tasks at runtime. You can depend on them from Gradle, you can enhance them from
Gradle, you can even declare dependencies on Gradle tasks in your build.xml. The same
integration is provided for properties, paths, etc ...
Gradle fully supports your existing Maven or Ivy repository infrastructure for publishing and
retrieving dependencies. Gradle also provides a converter for turning a Maven pom.xml into
a Gradle script. Runtime imports of Maven projects will come soon.
Ease of migration
Gradle can adapt to any structure you have. Therefore you can always develop your Gradle
build in the same branch where your production build lives and both can evolve in parallel.
We usually recommend to write tests that make sure that the produced artifacts are similar.
That way migration is as less disruptive and as reliable as possible. This is following the
best-practices for refactoring by applying baby steps.
Groovy
Gradle's build scripts are written in Groovy, not XML. But unlike other approaches this is not
for simply exposing the raw scripting power of a dynamic language. That would just lead to a
very difficult to maintain build. The whole design of Gradle is oriented towards being used as
a language, not as a rigid framework. And Groovy is our glue that allows you to tell your
individual story with the abstractions Gradle (or you) provide. Gradle provides some standard
stories but they are not privileged in any form. This is for us a major distinguishing features
compared to other declarative build systems. Our Groovy support is also not just some
simple coating sugar layer. The whole Gradle API is fully groovynized. Only by that using
Groovy is the fun and productivity gain it can be.
The Gradle wrapper
The Gradle Wrapper allows you to execute Gradle builds on machines where Gradle is not
installed. This is useful for example for some continuous integration servers. It is also useful