Built Tool Comparison

What Can The Build Tools Learn from One Another?

Jessica Thornsby

Part three of our interactive build tool comparison.

In part three of our interactive build tool comparison, we ask build experts from the worlds of Gradle, Ant and Maven, what their build system can learn from the other tools out there….

JAXenter: What can your build system of choice, learn from other build systems?

Hans Dockter (Gradle) : We have obviously learned from Ant and Maven, and much of this is incorporated into Gradle. But now, this process is more or less complete. In the future, Gradle will learn mostly from build systems related to other platforms and languages. These often provide very powerful features that we don’t have in the Java world – features many people are unaware of. One example of such a feature is a powerful, generic incremental build. We have implemented this feature in Gradle 0.9. Another interesting feature, are the rule-based approaches which are applied to input / output patterns. These help to define transformations, for example files which match a certain pattern. Rake and SCons are two build systems we’re taking a closer look at. Basically, we think a ‘Rich Model’ for the input and output is very important for implementing efficient solutions for parallel and distributed builds.

And finally, there are other nice things we want to offer soon, such as incremental testing.

Matthew McCullough (Maven) : I see three things that other build systems and their uptake communicates back to the Maven ecosystem.

The first is an observation that library dependency management, and even further, transitive dependency management, is a difficult but necessary challenge that all modern applications face and all build systems must address. Maven has led the charge on this front for the last eight years, providing a central repository that has continually improved in quality over time, and has made dramatic improvements with Sonatype’s OSS hosting and mirroring [link] facilities over the past year.

The second observation is that the community will contribute more in terms of feedback, suggestions, testing, and fixes the more you offer them easy channels to do so. In the case of Maven, with many of the ancillary projects having moved to GitHub, the barrier to contributing is as near zero as is technically possible today. Without any permission, you can simply fork a project, contribute new code or fixes, and then issue a pull request to the core development team. No patches, and sometimes, no JIRAs. Just quick community contributions.

Thirdly, other build systems have shown the community’s appetite for graduated steppes in a tool’s means of being extended. A new Maven plugin can be the right choice, but smaller enhancements can be convenient too. Today, in Maven, these take the form of import scoped dependencies, inheritance, archetypes, antRun scripts and gmaven scripts. In the near future, these will include polyglot macros, POM mix-ins and pluggable providers for facets like settings.xml.

While I am deeply engaged in the Maven segment of this space, I would like to thank all the contributors to the Maven, Ant, Gant, Rake, Buildr and Gradle projects, as they allow all developers on the JVM to be the ultimate winners in this ecosystem of healthy build-tool options with strong competition. Thanks for letting me contribute to the Maven facet of this comparison article!

Jan Matèrne (Ant) : Dependency management and standard methods. With Maven, you can begin a build without “major intervention,” and with automatic dependency management. Maven builds can also leverage the existing, well-stocked repositories and free RepositoryManagers.

Meanwhile, Ivy offers the possibility to integrate this functionality into your own build files, while placing an emphasis on flexibility, just like Ant. Thus, with Ivy it is not only possible to configure which artifacts should be used, but also how to resolve versions, how to handle conflicts (e.g, Modul-A needs Version 1 of C, Modul-B needs Version 2,) and even to define what form those artifacts take (JAR files, XSDs, Word, etc …)

Maven receives information on what to do with a project, from the Project Object Model (POM.) What I like about this approach is that you can finish the configuration with minimal effort. All routines are based on data in the POM.

With Ant, everything is configured at the level of Tasks. This means that configuration cannot be changed without damaging backward compatibility – however, there is a prototype “Autoconf” mechanism for introducing “Configuration by exception” in Ant.

The standard routines that Maven performs are implemented in plugins, for example the generation of Javadoc files. These standard routines are specified in the POM or inherited over the SuperPOM. With Ant, it is possible to define a set of standards, for example in a company-network or over the internet, which are then incorporated by the command

Since Ant 1.8, it has been possible to import URLs. I see two potential dangers here: firstly, it makes me dependent on the continued availability of the URL, and secondly, I have to trust the content of the URL. If the URL is maintained by your company this might not be a problem, but over the Internet? Even the Apache-Server has been compromised, in the past!

JAXenter: Thank you to all our experts, for taking part! For more information on build tools, be sure to check out part one and part two of our comparison.

Inline Feedbacks
View all comments