Well, I'm finished evaluating Maven; it does everything I need it to, and did so flawlessly (with one exception) for my needs. The exception was a slight inconsistency in how command line parameters get passed to the SCM plugin, which was very easy to find a workaround for.

Everything else did what it said on the box, and altogether Maven and its army of plugins has allowed me to set up a proof of concept build automation environment for our Java applications. I was able to do all this in the same amount of time it took me to get 20% through the same proof of concept when using Ant and BeanShell as the build tools.

I've found a lot of people blogging about how they are really pissed off with Maven, that it doesn't work, and that they will never use it again. To be honest, I'm really not sure why they had so much grief. The only thing I can think of is that they tried to use Maven for use cases for which it wasn't intended; maybe they were trying to write build scripts instead of follow Maven's conventions, or maybe they weren't up to the task of digging for documentation when needed. I can certainly say that after working with several open source projects with spotty documentation, I've developed a pretty keen sense for where to look (hint: mailing lists and sample code are your savior). Maven's documentation is spotty in areas, and I did have to dig a little to understand some of the plugins properly, but it certainly wasn't as intense as the digging I had to do to get in to the depths of other projects such as Mule or ActiveMQ.

I've also seen that large, popular open source projects such as Spring and Hibernate use Maven for their builds. If Maven was really such a pain in the ass, I'm sure people with minimal patience for tedium such as Rod Johnson and Gavin King would have avoided it for another solution (or rolled their own). As late as 2.0.5, Spring was still using Maven 1.0. I've been using Maven 2, which is supposed to be a drastic improvement, so I can only imagine how building a project as complex as Spring would have been with the previous version. Apparently, they managed.

Anyway... experience mismatch aside, I'm ready for the next step, which is to evaluate Buildr and potentially port what I have in Maven over. I looked through Buildr's manual (very nice docs, by the way), and it looks dead simple. I'm no Ruby slinger, but Dan is, so between he and I I'm sure we'll figure it out in short order.

First impressions of Buildr indicate that it does everything Maven does, but in script instead of XML. I'm not sure if I like this better or not. Script has its advantages; for example, Maven would be a total pain in the ass to script anything in. Your options are (a) write a Java plugin (read: learning curve), or (b) jump in to an Ant task and try scripting there (read: slow, painful, and unrewarding).

However, a lot of the stuff I've done in Maven makes perfect sense as configuration info in XML, since it's all convention based. All I've had to do is indicate which plugins I want, where my SVN repo is, what my project is called, and other info that is static and non-programmatic. However, an example of where Maven would fail me is when we deploy one of our web apps which requires symbolic links to be set up in the deployment directory after the code is staged. There would be no easy way to do this in Maven, whereas in Buildr I'm sure we'd just script the commands from Ruby over ssh.

After skimming the Buildr documentation, there are a few things I think it might have a hard time matching when compared with Maven.

1) Plugins. Maven's got them by the truckload, and the ones I played with were all really good and easy to configure. There doesn't appear to be a bridge for using Maven plugins in Buildr; all Buildr replaces is the Maven build script/config file.

2) Overridable project configuration inheritance. Maven makes setting up a global configuration for a development team to share a total breeze. When said developers create a project, they just create a minimal config file with the differences between their build and the global one. In my POC, all you need to do is copy down the pom.xml file for a project from Artifactory and run a command from the command line, and so long as you have the global config file in your local Maven repo, Maven will checkout source, resolve dependencies, build, test, and deploy the project with no further intervention.

On the flip side, there are a few things Buildr clearly has over Maven.

1) Handling of non-JAR/WAR/POM resources. I think there might be a way to do this in Maven, but Buildr makes it super simple. We need a way to manage non-Java resources in our build lifecycle (such as pure ColdFusion projects, or CFCs as dependencies), and Buildr seems to have elegant solutions for these problems.

2) We talked about scripting functionality. It's important enough that I'll mention it again in case you're not getting the point. :)

Dan and I should be tackling the full comparison this week, so I'll post back with the results once they are in.