Maven vs. Gradle vs. Ant

JAXenter sets out to find out which is the best build tool – Maven, Gradle or Ant?

‘Which is the best build tool?’ is a hot topic of debate
within the community – but what do representatives of some of the
most widely-known build tools, think about the build tool debate?
In our interactive build tool comparison, we speak to the people in
the know when it comes to three popular build tools – Maven, Ant
and Gradle. Hans Dockter will represent the Gradle Build system,
Matthew McCullough will defend Maven and Jan Matèrne will speak on
behalf of Ant.

In the first three parts of our four part build tool
feature, we will put our own questions to the three representatives
– but in part four, we’re asking YOU to pose the questions.
Questions can be included in the comment section at the end of each
article or, if you’re feeling shy, they can be emailed directly to
the JAXenter staff via the website Contact Form.

JAXenter: Hello! What was – and is – the main
focus in the development of the your own particular build
system?

Hans Dockter (Gradle): We believe that project
automation is an essential component of successful software
development. The requirements of project automation have increased
significantly in recent years, and now go far beyond the
traditional build. We want our tool to make it is as easy as
possible to meet these requirements.

We are convinced that the declarative approach is the key to
easy-to-maintain and extensible Enterprise builds. With the word
‘declarative,’ we mean that the user only needs to determine the
‘what’ and not the ‘how.’ An example of a declarative element is
the Maven packaging and dependency element. Users can define
whether the project is, for example, a Java or Web project
(‘what,’) and which dependencies it has (‘what.’) The ‘how’
(compiling, copying resources, retrieving of dependencies, etc …)
is then figured out by Maven. This is not to be confused with
build-by-convention, and also works for a custom layout. Then, one
only has to give a few more specifications about the ‘what’.

* It is possible to customise the behaviour of the standard
elements, or add your own language elements (via plugins or
directly in the build script.)

* All the features are integrated into the build-by-convention
approach.

* The declarative elements form a language. The users can use
this language to model their project at a high level of
abstraction. Often, the build master creates the model for the
entire department or organisation, and makes it available as a
plugin.

* Gradle also offers a plugin that implements a standard Maven
layout. However, this layout is not privileged and you can extend
this plugin (for example, have the integration tests in the same
project.)

Declarative elements can be very powerful. Gradle, for example,
provides the source-set-element for describing the ‘what’ of a
logical group of sources (such as location, class paths, etc….)
The user need only declare such an element, to automatically
receive the appropriate actions for it (compile, resource handling,
…)

The declarative layer is based on a powerful imperative layer,
which can be accessed directly as required.

Gradle allows the user to structure their build-logic
appropriately. It does not enforce indirections if they are
unnecessary, but can allow them in a high degree if required. With
Gradle, you get a build system where it is possible to apply the
common design principles of software development. We believe this
is very important for non-trivial builds. Simple builds are also
easy to implement in Gradle. Gradle scales very well to your
particular requirements.

In our experience, performance is often a major problem for
builds. This is particularly true of builds that automate as much
as possible. Gradle scales very well in terms of performance. There
are huge enterprise builds which use Gradle productively (the
largest has nearly 700 sub-projects). Gradle’s features, such as
the incremental build and the parallel execution of tests, can
often reduce the average build time dramatically.

Gradle welcomes the unexpected. We are always surprised and
amazed at the unexpected needs of our users, and pleased that
Gradle provides a way to implement them. Gradle’s extensible build
language is one of the factors that facilitates this. Another, is
the huge amount of powerful extension points into which one can
plug in custom code to make the necessary adjustments. This applies
to the configuration of the build, in addition to its execution. To
take just one example: with Gradle it is very easy to expand a CI
build so that it sends an email to the author when a unit test in
the Package com.mycomp.db lasts longer than one second. You can
also expand Gradle with your own extension points (via plugins or
init scripts.)

Matthew McCullough (Maven): The focus is to
provide the most consistent and simple out-of-box experience for
Java-based builds that require code compilation, dependency
management, unit testing, production of an archive (JAR, WAR, or
EAR), project reports, and invocation from a continuous integration
server.

This often resonates well with large organizations and
enterprises, but has also had great uptake in the open source
community. A quick survey of the percentage of projects at Apache
that use Maven offers a testament to the desire for cleanliness
that a Maven build can bring to the organization and compilation of
a product.

Almost for free in terms of XML (not) written, the developer
receives ancillary benefits of project reports on JUnit test
execution success, code coverage, JavaDoc, HTML formatted source
code, static analysis and more. For the many common workflows, the
project definition XML for Maven is quite minimal. And for
developers that are, in these resource-cautious economic times,
required to work on more than one project, the strong consistency
of Maven’s project object model is a lifeline to quickly
understanding the builds of many disparate systems.

Maven continues to support the foundational goal stated above by
having the best and greatest number of plugins to continuous
integration servers like Hudson and Bamboo. In fact, a Maven build
can be almost effortlessly woven into Hudson by merely pointing
Hudson to a project’s POM as it rests in an HTTP accessible
repository. The source code location is harvested from the POM, as
are the source patterns to compile, classes to execute as unit
tests, and dependencies to download and bundle.

In sum, Maven hits the sweet spot of making a build engineer’s
life a pleasant experience through descriptive (not imperative)
corporate definitions of common build facets, object oriented
inheritance of build attributes, and strongly opinionated defaults
for elements like source code locations.

Jan Matèrne (Ant): Backwards compatibility. Ant
can be used on various systems, ranging from machines that have not
been updated for ages, to brand-new computer systems.

With Ant, we place an emphasis on providing support for old
versions of Java and old build files. It was only with Ant 1.8 that
we upgraded to Java 1.4! And Java 1.4 should be readily available
to all computer systems nowadays. But, if Java 1.4 isn’t installed,
the developer can still use Ant 1.7.1, which requires Java 1.3.

The disadvantage of maintaining this sort of support, is that
the new Java 5 features unfortunately cannot be used in the Ant
core area. But, knowing that one’s program can pretty much run
everywhere, is important.

Another core requirement for new versions of Ant, was that old
build files would still be accessible. And, with few exceptions, we
reached this objective. Even old Ant 1.3 build files still work on
new versions of Ant. In addition, previously written tasks work
with the newest versions of Ant, which is a big advantage when
working with the many existing extensions.

Have a question for either Matthew McCullough (Maven),
Hans Dockter (Gradle) or Jan Matèrne (ANT)? Leave your questions
below, or email JAXenter via the online Contact Form – and be sure
to check out part four, where these three experts will be answering
YOUR questions!

Matthew McCullough is an energetic 14 year veteran of enterprise software development, open source education, and co-founder of Ambient Ideas, LLC, a Denver consultancy. Matthew is currently a member of the JCP, reviewer for technology publishers including O’Reilly, author of the upcoming ‘Presentation Patterns & Anti-Patterns’ book, multi-year speaker on the No Fluff Just Stuff tour, author of the DZone Maven, Git and Google App Engine RefCards. He channels his teaching energy through activities as President of the Denver Open Source Users Group. His experience includes successful JEE, SOA, and Web Service implementations for real estate, finance and telecommunications firms in addition to publishing several open source libraries. Matthew jumps at opportunities to mentor and educate teams on how to leverage open source. His current topics of R&D are Cloud Computing, Service Integrations, Maven, Git, and Hadoop.

Jan Matèrne

Jan Matèrne is a software developer in the computer centre of the financial NRW. His interests lie in build automation and code generation. He has worked with Ant since 2000, has been a committer since 2003, and since 2004 he has been a member of the PMC. Outside of Ant, he is active in the Hudson and Args4J projects.

Hans Dockter

Hans Dockter is the founder and director of Gradle and the CEO of Gradle Inc. He has 12 years experience as a software developer, project manager, architect, trainer and mentor. In olden times, he was also a committer for the JBoss project and created the JBoss-IDE.