Adam has posted 1 posts at DZone. View Full User Profile

The future of Java build tools

02.24.2009
| 24654 views |
  • submit to reddit

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

Published at DZone with permission of its author, Adam Pohorecki.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Brian Schlining replied on Tue, 2009/02/24 - 3:05pm

Regarding:
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.
It seems that not many people realize this, but you can incorporate Maven into your build.xml file and use it for dependency management for your Ant build stuff (in the same manner as Ivy). An example is at http://hohonuuli.blogspot.com/2007/03/boostrapping-mavens-antlib-maven.html

Nicolas Labrot replied on Tue, 2009/02/24 - 3:46pm

I totally aggree with this article.

Build tools like Gradle are the future but actually too fresh.

 

 

Marius Scurtescu replied on Tue, 2009/02/24 - 6:20pm

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. I think you are mixing two totally different things here.

 

The syntax for Ant scripts is XML, but that does not mean that the programming language is XML. I agree that XML is far from ideal, but syntax aside, Ant's programming language is quite powerfull. There is a reason while makefiles have been around for so long. Methods and conditionals are available in Ant as well. You don't have loops and I never run into a situation were I really needed them, there are other ways to acomplish the same thing.

It helps if you think about Ant as a functional language, as opposed to an imperative one. We all want Ruby, Groovy or some other imperative language because we are used to them, not because they are better.

 Is Haskell a lesser language because it does not have variables and for loops?

phil swenson replied on Tue, 2009/02/24 - 7:19pm in response to: Marius Scurtescu

XML was never intended as a programming language.  Once you get past simple tasks, XML for ant falls apart.  I need conditionals, variables, loops all the time in Ant.  Yes, you can do loops and conditionals in ant, but it's ugly, awkward, and very difficult to debug. With Gant I can hook up my debugger and step through it.  Try doing that with Ant.

Look at a build.xml.  It's very repetetive.  This is largely because you can't write functions in Ant.  If you wrote java code that was so repetetive you'd be laughed at.

What possible advantage is there to XML?  I can't think of any.

Do you write shell scripts in XML?  Absurd?  if it's absurd for a shell script, why not for your build?

Michal Galet replied on Wed, 2009/02/25 - 2:41am in response to: Marius Scurtescu

The syntax for Ant scripts is XML, but that does not mean that the programming language is XML

Actually, for Ant scripts you are programming in XML!

It is possible to write some complex things in Java and than call that from Ant. But that is not going to solve the complexity of the build script. Besides DM, one of the biggest advantages of Maven are conventions and fixed lifecycle. When you switch between projects you know exactly how to compile, test and package it. I remember Ant projects that took 1 day of configuring just to compile and package it. Not to mention the awkward release cycle.

I evaluated Gradle a few weeks ago. It is very, very promising and I look forward to try it on a real project. It just needs to become more mature with IDE integration available. And of course Maven-like support in Hudson would be nice:)

Vassil Dichev replied on Wed, 2009/02/25 - 4:01am in response to: Marius Scurtescu

There is a build tool, which is both using a powerful programming language for configuration and properly functional- Lancet. It uses Clojure, which is functional and lazy, so you can use function composition and programming constructs much more powerful than what Ant can do.

If you despise learning a new language, don't try Lancet, but it's a good excuse for a dip in a modern LISP.

Paul Grove replied on Wed, 2009/02/25 - 8:25am

When Gradle is supported by Hudson and Sonar and can produce all the reports Maven currently can I will gladly get the team to switch build tools

Nicolas Labrot replied on Wed, 2009/02/25 - 10:53am

As far as I know, Hudson support Graddle.

Sonar is another problem... Depending on a unique build system is in my opinion an error...

 

Marius Scurtescu replied on Wed, 2009/02/25 - 5:03pm

Thanks for the heads up Vassil. Lancet looks interesting.

Marius Scurtescu replied on Wed, 2009/02/25 - 5:12pm in response to: Michal Galet

Actually, for Ant scripts you are programming in XML!

http://stefan.samaflost.de/blog/en/Apache/Ant/ant_javafront.html

Roger Voss replied on Thu, 2009/02/26 - 11:10am

"However, given a choice “Ant or Maven”, I would most likely choose the former."

 A better choice is to use both together in some cases. Here is what I mean:

 For greenfield projects we're using Maven. Is definitely easier to make a new project conform to Maven than it is to make an existing legacy project do so.

 However, our legacy projects use ant. So we have been going back and modifying these ant-based projects to use the Maven ant task and adding in pom.xml files to manage all their dependencies.

 This is a really great approach because essentially we get one of the very primary benefits of Maven and even greatly simplify the definition creation of the various classpaths that are used in the ant build.xml files. Indeed, we are able to use Maven's scope concept to form classpaths that are tailored to the different use situations in the ant build.xml file, such as a classpath for compiling, a classpath for running unit test, a classpath for packaging (and embedding some dependencies while assuming others will be provided), etc.

 I highly recommend this hybrid approach for legacy Java projects as it works extremely well and enables Maven dependency management to be used universally for all projects.

Ivan Lazarte replied on Tue, 2009/03/03 - 12:02pm

Maven's been a disaster on our greenfield. I'm labeling maven as the ejb of the build tool sets, therefore I'm not surprised Adam loves it so much. Ant literally takes minutes to setup and run. What is the problem? Is it that builds are too fast and uncomplicated so we can't generate more work to suck profts from clients? Ant rules.

Matt Green replied on Sat, 2010/01/23 - 1:43pm

"use it for dependency management"

This may come as a shock, but if you're using (e.g., Maven's) transitive dependencies, then they are not "managed".

 "managing" dependencies is not really possible (at build time), in the full sense of the term, since dependencies may exist via reflection and can only be checked at runtime by a classloader that checks those things (such as the NetBeans module system, or OSGi).  Maven of course doesn't do this, it only builds the project. Once it's built, Maven disappears (still not soon enough for my tastes, however).  The problems, however, don't.

 Also, using transitive dependencies may (obviously) lead to a situation where another project includes different versions of the same jar.  Which version does Maven use?  These kinds of questions should not even need to be considered by the programmer, since such situations should be excluded by design.

Another issue: how do you remove a jar from a project?  You may break upstream dependencies. So Maven actually encourages practices which destroy modularity.  And all of this in a wacky XML language that's impossible to debug!

 I guess nothing dies more slowly than a bad idea.

 I am overjoyed at seeing the new build tools, the sooner the Java world dispenses with Maven the better off we'll all be.

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.