Our build is now Maven-free, and I couldn’t be more pleased. I found that Ant 1.6.2, ant-contrib, and Ivy make for a really good Maven replacement.
I realize it’s been out for over a year, but Ant 1.6 is a huge improvement over previous versions. Macros and imports make life so much easier when writing complex build scripts. I especially love the ability to simulate Maven-like pre- and postGoals with the import feature. It’s even more flexible than Maven in this regard, as Maven doesn’t allow preGoals and postGoals to have prequisites.
Ant-contrib has some nice tasks that make writing ant files easier. It makes ant more like a scripting language than a makefile, but sometimes pragmatism has to win out over purity.
I’ll save comments about Ivy for another post. Needless to say, I’m pretty pleased.
As expected, our build times with ant (especially when running automated tests) are now significantly faster than they were with Maven, and without that out-of-memory annoyance. A comment from Scott Farquhar suggested that Maven, like Ant, could also have its unit tests configured to run in a single, separate thread. That this option is not listed in the maven documentation for this feature is, I feel, representative of the sad state of Maven plugin documentation. However, when I actually tried this on a branch that still has the maven build running, the majority of the unit tests failed due to a LinkageError when loading the Node class. Google suggests others have run into this issue, as well. At this point, I refuse to read another line of Jelly to figure out a problem in a build we no longer support.
The biggest downside to this change is that we’ve lost all the features that came for free from the default set of Maven plugins. I’ve been able to get the important features (such as war file generation, JSP compilation, and appserver installation and control) replaced with some custom ant import files. I’m currently working on a replacement for the Intellij IDEA maven plugin.
For any Maven lovers who may stumble upon this post: I have no doubt that Maven works amazingly well for you, and chances are quite good that the reason I couldn’t get it to work the way I wanted is because I’m a moron.
I’m fine with that. I hope you are too.
house of haug 
I haven’t looked at it in awhile, but genjar (http://genjar.sourceforge.net/) might help with WAR file generation. We used it on the last project I was on and it helped a lot.
ThunderBob!
Thanks, but war file generation is covered. I’ve got the essentials down great. Things like the ‘idea’ target for generating IDEA files with all the dependencies, and the ‘site’ target for generating web pages that show all the various reports, are the standard maven targets that are still missing from my new ant build.
I’ve done something conceptually similar. My project is a set of netbeans modules. The ant scripts for netbeans are actually quite similar to ant+ivy (they have their own module system and a project.xml file for declaring dependencies between the modules). I wrote an ant task that reads in all our project.xml files, and generates eclipse .project and .classpath files. It might just be an xslt script or a java class runnable as an ant task for you to read in your ivy files and generate .ipr and .iws files.
However, I say this without ever having seen an .ipr or .iws file.
Did i get anything wrong here? War file generation is not really hard in ANT isnt it? But generating IDEA project files will be a tough one. To be honest, i wasnt aware that Maven is capable of this. Of course, even knowing it and being an IDEA user wont change my mind about Maven in general.
I also dont get the whole hype around automatic jar dependency mechanisms like ivy. I am still checking my jars into my repository and so far things are ok with that approach. Perhaps there is something i am fundamentaly missing on that topic.
Perhaps i am a moron too 😉
Hi, Marc. Thanks for the comment.
No, WAR file generation in ant isn’t hard at all (it’s got its own task, after all). I didn’t mention it because I had to jump through hoops to implement it. It was just another one of those things that was handled automagically by maven that I had to address explicitly in ant, even if said address is trivial.
As for dependency management tools like Ivy and Savant, I think their original raison d’être is to assist with multi-project builds, where different projects may require different versions of the same tool.
For me, I like Ivy merely as an organizational tool for dependencies. Currently, our application uses more than 40 3rdparty jars. Many of them are not used by our application directly, but rather as dependencies of dependencies (ad infinitum). With Ivy, I now have a full accounting of what libraries our project relies on directly. The latest version of Ivy even has graphing and reporting capabilities, so you can see visually the fanout of dependencies for your project.
Sure, I could just check all the jars in. And I may do that, after I implement a subversion resolver for Ivy. But after some initial configuration, I find that having Ivy handle this to be worth the effort. We now have clear understanding of our dependency tree, rather then relying on ad-hoc documentation to figure out, for example, why exactly we’re deploying commons-codec again…
whew!! that header made me think i’m getting into a horror site..
We’ve been using Ivy for about 1.5 years just for the dependency accounting. We also use IvySVN and check in our binaries into subversion, which gives us jar history and commit comments. Dependency management is tedious IMO but paring ant with ivy with ivySVN seems to be the lesser of all evils.