Maven vs. Gradle vs. Ant
JAXenter sets out to find out which is the best build tool – Maven, Gradle or Ant?
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 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 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.
‘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’.
Gradle takes Maven’s declarative approach a step further. With Gradle:
* There are declarative elements on different abstraction levels.
* 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!
Read more at part