Over a million developers have joined DZone.

The future of Java build tools

DZone's Guide to

The future of Java build tools

· Java Zone
Free Resource

What every Java engineer should know about microservices: Reactive Microservices Architecture.  Brought to you in partnership with Lightbend.

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 summ 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.

UPDATE: A follow up to this post has been posted here

From One more commit

Microservices for Java, explained. Revitalize your legacy systems (and your career) with Reactive Microservices Architecture, a free O'Reilly book. Brought to you in partnership with Lightbend.


Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}