Ant vs Maven

[Pradeep bhatt]

Which is better and why?

[Lasse Koskela]

Ant and Maven are so different that I think it's useless to claim one is better than the other.

Here's what I think of them, without having used Maven beyond one brief tryout a year or so ago:

Ant is a must-have for any Java project. I simply can't come up with a good reason not to use Ant for building your stuff unless you're talking about a "sandbox" project where you just want to check whether something can be done using java.foo.bar.Something.

Maven, on the other hand, is a lot of complexity that doesn't bring much added value over Ant for most projects. The things I see as being Maven's strengths is that it fetches the correct versions of 3rd party libraries for you if you don't happen to have them locally, and that Maven generates a web site for you including javadocs, unit test results and that sort of stuff. The problem I had (have) with Maven was (is) that it was simply too much complexity for little gain.

Others' mileage may vary.

[Bear Bibeault]

Others' mileage may vary.

Not mine. I too think Ant is an indispensible tool for anything other than a single-file project. So many of the "I'm having problems compiling 'such-and-such'" problems reported in other forums could be so easily solved by adopting ant and, once the build file is set up, forgetting about the build and just letting it do the work for you.

Maven I found to be an interesting exercise, but too complex for what it does for you.

Others' others mileage may vary.

[Glenn Murray]

Hi,

I thought I'd insert my contrary opinion. I have not used
Maven because it is too simple, not too complex. I think
the idea of Maven is to provide a development environment
standard, and this it does simply and well. Unfortunately
for the project I was working on, Maven did not have
the flexibility to adapt to the existing directory structure.
However, its out-of-the-box features for code metrics and
the nasty jar versioning issue are very attractive, and far
simpler to deal with than trying to customize Ant.

Cheers,
Glenn
[ September 21, 2004: Message edited by: Glenn Murray ]

[Ernest Friedman-Hill]

I'm going to add my own contrary opinion, too, because, well, because I can.

Back before I'd ever used Ant, I used to wonder why people seemed to prefer it so strongly to "make." My hypothesis was that perhaps most big Ant fans had never used make on UNIX, and so didn't know what they were missing. But it was on my list of things to try, because maybe I was wrong.

Now that I have used Ant for several applications... I still have the same hypothesis. When forced to use Windows, I'd much rather build using make under cygwin. With make, you can quickly write a line of shell code to do anything you can imagine. With Ant, if you're lucky enough that someone's already implemented the target you need, you have to look up the special syntax, type a minimum of three lines of XML, and then be content with the behavior that the author of the Ant task built in. If you're unlucky, and your task doesn't yet exist... well, you're in for a lot more than just writing a shell command.

The one place where I think Ant is an improvement is if you need to ship build tools -- i.e., in open source projects. The "make" configuration issues that are easy to deal with among one project group become much more difficult if you have to work with Joe Coder from the Internet's setup. The price you pay for this, of course, is lack of power.

Anybody who wants to try again to sell me on Ant, go right ahead.

[Mike Clark]

I agree with what others have already said here. In my limited experience using Maven, it adds more complexity than it's worth without offering a commensurate amount of flexibility. For most projects I find Ant to be sufficient and I have full control over how Ant builds my projects. That is, I can see under the hood of Ant and tweak things as necessary for the project. Seeing under the hood means that I'm exposed to a certain level of detail that some may find daunting, and thus the abstraction that Maven provides is seen as being simpler by some folks and more complex (unwieldy) by others.

I tend to start with simple tools and then build up. I see Maven as a layer atop Ant, and so I'd rather start with Ant and then evolve toward Maven if it offers something I need. I'd consider starting with Maven if I wanted to enforce a common project structure and build artifacts across many projects. Open source projects, for example, can present a common view using Maven and manage the dependencies between projects.

I'll continue to keep an eye on Maven as it matures. In the meantime, I think having a good understanding of Ant is a valuable skill and it puts you in a better position to understand how Maven works. That's primarily why I chose to focus on Ant in the book.

Mike

[Lasse Koskela]

Originally posted by Ernest Friedman-Hill:
Anybody who wants to try again to sell me on Ant, go right ahead.

Not that I would feel a need to sell you anything, I've got a couple of questions about your use of make:
1) Are you developing J2EE applications?
2) Would you mind sharing a piece of your typical make files that compile Java code buried in a complex package hierarchy?

[Mike Clark]

Originally posted by Ernest Friedman-Hill:
Anybody who wants to try again to sell me on Ant, go right ahead.

As much as I bemoan XML, I still think Ant has a lot to offer Java projects over make. Specifically, the availability of common Java build tasks makes Ant a compelling choice. For example, I think being able to share custom build steps such as 'war' across a project saves time, improves accuracy, and increases productivity. That is, while make is a generalized build tool, Ant is a specialized build tool.

Also, I see more teams using a mix of operating systems for development. I happen to use Mac OS X, for example. In those mixed environments, I think it would be difficult, though not impossible, to consistently write portable makefiles. And modern IDEs are starting to support an externalized build process using Ant, and I wouldn't want to miss out on that.

That said, I still use make quite frequently because it's a great general-purpose automation tool. For example, while writing the book I generated the PDF version by typing 'make book.pdf'. That step went through all the motions of converting plain text into XML and ultimately into PDF. In that case, make was the right tool for the job.

Ant certainly falls down when we try to use it as a scripting language, as some have tried at their own peril. When my build process requires the facilities of a scripting language, I'm looking to other specialized tools such as Groovy's Ant markup. It's XML-free and gives you all the power of Java right there in the build file.

I don't expect this will sell you on Ant. Heck, I wouldn't consider myself sold on Ant. And the book has a story from Ant's author expressing his concerns for its misuse. But right now I think it's the best build tool for Java environments, relative to the other options. I look forward to somebody writing the Ant killer someday soon, and I don't think it's called Maven. :-)

Mike
[ September 21, 2004: Message edited by: Mike Clark ]

[Ernest Friedman-Hill]

Originally posted by Lasse Koskela:

1) Are you developing J2EE applications?

No, and you're right, the large volume of pre-written J2EE tasks is a good pro-Ant argument, because otherwise you'd have to write that stuff yourself.

2) Would you mind sharing a piece of your typical make files that compile Java code buried in a complex package hierarchy?

The vanilla stuff -- enough to compile (with dependencies) all the source files in the tree rooted at "com" -- looks something like this (remember that make doesn't know about Java by default, so a lot of this is boilerplate that you can have in a common, included file.

.SUFFIXES : .java .class
 
PLATFORM:=$(shell uname | cut -c 1-6)
ifeq ($(PLATFORM), CYGWIN)
  FIXPATH=cygpath -p -w
else
  FIXPATH=echo
endif
 
JAVAC=jikes
JAVACFLAGS=+D -g -nowarn
CLASSPATH= $(shell $(FIXPATH) whatever.jar:wherever:something.jar)
 
.java.class :
$(JAVAC) $(JAVACFLAGS) -classpath $(CLASSPATH) $<
 
SRC= $(shell find com -name '*.java' \
\! -name 'Xxx*' \
\! -name 'TMPLT*' \
  -print )
 
OBJ=$(SRC:.java=.class)
 
compile: $(OBJ)

This particular "SRC" definition ignores files named Xxx(something).java and TMPLT(something).java in the source tree. It could just as easily find only the files in certain subdirectories, or only the files containing interface definitions, or only the files that use a certain constant. "find" is very powerful.

I left the hairy "FIXPATH" macro in to show how we solve the Windows/UNIX CLASSPATH portability problem, which is the one real curveball in all of this.

Now, if you aren't a UNIX person, that probably looks like Greek. But so do build.xml files to the untrained eye, and the cool thing about it is that if you speak "Greek," anything you can say, works.

[Bear Bibeault]

Anybody who wants to try again to sell me on Ant, go right ahead.

I won't try to sell you, but as someone who grew up with UNIX and make I can give you my perspective.

Having used make for about as far back as I can remember, I always loved what it did, but detested -- with a strong passion -- the ultra-whitespace-sensitivity and arcane notation of the makefile. Being a UNIX child, I certainly had no lack of exposure to arcane notation, but familiarity never bred acceptance in my case.

The very thing that attracted me to try Ant in the first place was one of the points you (I think) derided: XML syntax for the descriptor file. I prefer the somewhat wordy, but more descriptive, three lines of XML to a single line of cryptic notation. But I can understand how someone as comfortable with the make notation as we are could find this unecessary.

What kept me using Ant was, as Lasse mentioned, its Java-centricity. While it could be used for projects in any language, it's ideally suited for large Java projects (in my case enterpise-sized web applications) with intuitive support for things like the Java classpath.

As I recall, makefiles also had platform-specific issues (it's been a while so maybe this has been alleviated). As someone who has to deal with Windows, Mac OS X, and other UNIXes, I like the almost complete portability of the build.xml files. (All my build.xml files are completely portable; all machine-specific settings are specified in imported properties files).

While that may not have sold you, I hope it may give you some insight into how even an old UNIX grunt like me could prefer Ant over make.

[Ernest Friedman-Hill]

Mike makes some good points (really enjoyed the book, btw -- my review is posted if you haven't read it) and has planted the germ of an idea into my head about Ant and why it's good.

Ant isn't supposed to be a good build tool for general development. It's a specialized build tool that's good for some kinds of Java development.

J2EE apps are more or less all Java and XML, and any portability issues are standard things tools should address. Ant works great here -- why reinvent the wheel?

As I said before, Ant would is also great for 100% Java open-source apps where you have to provide build tools to Joe Coder.

But I've never done any serious J2EE work -- I do desktop development, primarily. One of my major projects has some necessary features that Ant just wouldn't handle well:

Native libraries, with Win32, Linux, Solaris, SGI implementations.

Documentation written in DocBook, from which we generate a manual, command-line help, and online help (with Oracle Help Viewer.)

Shell-script driven application tests which have to launch and twiddle with platform-specific external applications.

I can't imagine the pain of dealing with these things using Ant instead of Make, and I guess Mike's giving me permission to make the sensible choice here. Thanks for the insights, all!