Built Tool Comparison

What Can The Build Tools Learn from One Another?

Jessica Thornsby
What-Can-The-Build-Tools-Learn-from-One-Another

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.

Author
Comments
comments powered by Disqus