|
 The
Future of Java Build Tools
By Adam Pohorecki
With a short post
on dzone Adam Bien revived an old flame-war: should we use Ant or Maven
as our build tool. The post itself seems a little biased on the maven
side, but not much. The only really questionable sentence is:
The real strength of Maven is its dependency management. (…) Ant
doesn’t have such capabilities out-of-the-box (except via Ivy) and it will take a considerable amount of work to
emulate Maven’s dependency management with Ant.
Although it’s certainly true that Ant does not have
dependency management built in, it’s fairly easy to incorporate Ivy into
your build.xml, so the "considerable amount of work" part is in my opinion
rather misleading.
However, given a choice "Ant or Maven", I would most
likely choose the former. I can see why so many people today use Maven as
their primary build tool. It is pretty cool to have this drop-in build
script, that with only a few lines of configuration will give you so many
possibilities: dependency management, built in tasks for compiling and
packaging applications, integration with Jetty, neat project web site,
integration with cobertura, pmd or findbugs. In a situation, where one
starts a new project, which is fairly typical (say a web application using
Spring & Hibernate) this seems like a very good choice. I will say even
more: for a project like that, this is probably a good choice.
No one really wants to write build scripts. This is the
kind of code that does not have any real business value. Unfortunately that
last statement holds only if the build script actually works, otherwise it
has business value: a negative one. I feel that a build system like Maven
is really great until you start encountering problems with it. Maybe your
project just does not fit so very well in the convention. Maybe plugins you
want to use conflict with each other. There’s lots of points of failure
in a build system like Maven - and oftentimes it’s very hard to track the
source of them and fix them.
The choice of Ant over Maven is not a very clear one. It
truly is a chore to be forced to write all this build code by hand. But
when the things go south, the build script is just another piece of code
you’ve written. If you did it right, you should be able to find your way
around that code, and fix it. No magic here.
OK, I’ve written enough to spill some oil to the
flame-war fire. Now to the point of this article: are Maven and Ant our
only choices? Is there really nothing better than that?
I claim there is. Over the last couple of years we’ve
seen many such projects spring up to life. Those tools no longer use XML to
define build logic, but real programming languages like Groovy, Ruby or
Python(? - I thought I’ve seen an announcement somewhere for build tool
in Python, but can’t find it now). They often allow dependency management
(through Ivy or Maven) or Build By Convention. Some of those tools
are:
My favorite build tool was Gant, up until the first
release of Gradle was announced a couple of months ago. Gant is basically a
Groovy way of invoking Ant tasks, which by itself gives you a lot compared
to a good old build.xml. By using a real programming language instead of
XML, some tasks which could become tedious in XML, are very easy:
extracting common code into methods, loops, conditional logic (yes, I know
about ant-contrib
and use it whenever I have to use Ant, but trust me, it’s not the same).
The fact is, that XML is not a programming language and it should not be
used as one. Build scripts in languages like Groovy or Ruby are more
concise and easier to read. There’s less clutter, boilerplate code, and
your build script can be structured better.
In my opinion, the future of build automation in Java
environments is Gradle, or at the very least some other tool, which will
exhibit similar properties. Gradle is the kind of drop-in build script that
I like: for simple, standard projects it allows you to use itself with just
a few lines of configuration. It even allows transitive dependency
management without using Maven or Ivy repositories. You know, how when you
first learn about this "dependency management" thing, you wrote down your
dependencies in ivy.xml or pom.xml and it took forever while "Maven
downloaded the Internet"? How eventually you had to install a private
repository just to store those dependencies which could not be found in the
Maven repositories? How you had to fix pom.xml files, because some of the
artifacts didn’t declare all their dependencies? Well, now you can have
DM without all those problems. Just store the required libs in the SVN
repository, and switch to "real" DM when needed.
On the other hand, for bigger projects, among many other
features Gradle has first-class support for multi-project builds (for
example, you can specify project dependencies, and when you build one of
the sub-projects, all it’s dependencies will be built too). There’s
plenty of other features and cool "magic tricks" you can do with Gradle.
Check out the User’s Guide on the project web site. It’s about 100
pages long, and provides plenty of information. I mean it: you owe it to
yourself to give up an hour of your time and read that manual to see how
much better your life would be if you used Gradle :o)
That being said, I have to admit: Gradle might not be
suitable for "production use" yet. The project is still fresh out of the
oven - it’s less than a year old. It’s impressive how much Hans Dockter
and other commiters managed to achieve in that time, though. The
documentation is IMHO very good - short enough and informative. If you are
looking for a replacement for Ant - Gradle is the thing for you. If
you’re looking to replace Maven, you might want to wait a couple of
months, since Gradle does not have support for many of the features Maven
users rely on, like the project web site or generating project files for
main IDEs. There’s also currently no IDE support for Gradle.
To sum up: while there might not be a "one size fits all"
solution to build automation, new tools being developed seem to come close.
By allowing both build by convention, and combining it with
do-it-yourself-if-you-like approach Gradle has a shot at attracting both
Ant and Maven fans. In the future I expect build scripts to be written in
programming languages like Groovy or Ruby, and Gradle is likely to gain a
significant market share.
Until next time,
Adam Pohorecki
To
read more of Adam's work, visit adam.pohorecki.pl
|
Back to newsletter list
Perspective
