The Blog

Sep 19, 2007

Build Tools: Buildr 

by Maxim Porges @ 9:31 PM | Link | Feedback (0)

Dan's been spending the last week or so (on and off) porting my sample Maven build script over to Buildr. He and I got together today to review his work and compare Maven and Buildr side by side.

Hopeful Speculation
Going in to the evaluation, I was hopeful that Buildr would present a better alternative to Maven for a few reasons.

The first reason is that I see us scripting our deployment process to production in a scripting language, and that might as well be Ruby. Being able to have our entire build script and deployment process in the same language would give us a complete package.

The second reason is more forward-looking. Although I have found Maven to meet all of our needs so far, we're playing by the rules Maven defines, which doesn't really push Maven to its limits. I wrote a post on a ColdFusion Maven build script, and while I got it working using a modification of the resource bundling built in to Maven's build process, I wasted an hour or so before that trying to get Maven's Assembly plug in to do the same thing.

Some of the challenges people have had with Maven became a bit clearer to me after this exercise, but my hypothesis regarding them using Maven for alternative purposes seems to hold true. The reality is, Maven is very tightly coupled to Java build processes, and anything else really requires a custom plugin. Trying to bend Maven-standard scripts to your will to do something out of the ordinary seems to be an exercise in futility. Of course, one could argue that Maven is not designed as a scripting language, and this would be accurate - but limiting Maven to the scope of Java applications seriously limits its usefulness for new technologies that we're not using yet. This wouldn't be an issue with Buildr, since its Ruby-based nature would make it super easy to script up something unexpected in a jiffy. I would hate to set up an infrastructure based upon Maven only to find that we're stuck when we try to introduce something else later on.

Back to Buildr
So, Dan's port basically did everything that my Maven build did, with a few exceptions. Some nice things about Buildr include the following.

1) The scripting syntax is very terse, which makes sense since the guys who wrote Buildr wanted a DSL for building software. Maven's XML files are lengthy, and hardly complicated by any stretch of the imagination, but it is nice to have a short and sweet file like Buildr's to review when you're looking over something.

2) Buildr has all the power of Ruby, so the things that were built in to Maven but didn't exist in Buildr were pretty easy to code. Dan found a way to hook in to the Maven PMD plugin, to simulate profiles, and to allow for inheritance-based overrides, as well as writing some code to resolve transitive dependencies (something Buildr lacked, and which Dan submitted to the Buildr project for the next release). The ease with which Dan was able to add these items speaks well to the future applicability of Buildr to unforeseen requirements in our build process.

3) Buildr conforms to all the Maven conventions, so taking a Maven project and porting it over (or vice versa) is pretty straightforward. There's even a tool for porting POMs to Buildr scripts, which makes sense since Maven POMs are simple XML files and can be transformed to any format like any other XML document.

4) Buildr has Eclipse project integration, where you can check out your project from SVN and run a single command to create .project and .classfile files. The .classfile files uses an M2_REPO classpath variable to reference your Maven repository, so your library dependencies get resolved to your local Maven repository, removing the need to add them to your project as copied JARs.

Of course, there were also some cons.

1) Buildr doesn't work with Artifactory. Artifactory is basically the best option for a Maven-style repository that is out there, and I was actually surprised that it doesn't work out of the box as a default option. Dan has sworn to fix this and submit the code to the Buildr project, since this was a bit of a show stopper for us.

2) Although Buildr can create Eclipse projects and set up initial dependencies, it didn't really have a nice model for adding dependencies on the fly while developing. Maven's Eclipse plugin reacts to changes to the POM file, automatically adding libraries to the classpath and downloading dependencies if necessary. In the absence of a Buildr Eclipse plugin, a developer would be forced to run a command from the command line in order to simulate this functionality. This isn't a huge issue, but struck me as something that would quickly become an annoyance during development.

3) Buildr lacks source control management connectivity out of the box. We could certainly have scripted integration with SVN by issuing SVN commands to the command line from Ruby, but this would tie us to SVN. The nice thing about Maven's SCM plugin is that it is tool-independent; so long as you use an SCM supported by the plugin (which includes most popular ones), your build file requires no changes other than the protocol in the SCM URL pointing to your repository. Although I don't see us moving off of SVN any time soon, the independence of the plugin is a nice little bonus, especially since we might decide to go to a more mature commercial product such as Perforce at some point.

4) Maven has oodles of plugins for almost anything you can think of. Although Dan was able to invoke a few of the plugins from the command line, it required extra thought to put this in place, whereas Maven provides this capability out of the box.

5) There was no equal to the Maven's SQL plugin in Buildr. Being able to stage SQL scripts during development, QA, and production staging is going to be a really neat feature. I don't have this working completely in the Maven build yet but it shouldn't be a far stretch from the POC I did a few days ago.

6) There's no equivalent to Maven's site generation plugin in Buildr. Honestly, this would not have been a show stopper if it were the only item, but it was a detractor. In the early days, we had discussed adding site generation to our automated build process, and the fact that Maven has it is a nice bonus.

7) Finally, the fact that Buildr is in Ruby is a small challenge for us. We only have a handful of developers working regularly with Ruby outside of work, whereas everybody on the team is familiar with XML from Spring and Hibernate configuration and/or writing Ant builds. Adding a new language to the mix, while not the end of the world, just creates an additional item for us to train our developers on. Ultimately, I think this is going to be a moot point, since I'm very interested in exploring Ruby and Rails as platforms for developing our web sites and services in the future.

Ultimately, Maven won out between the two tools due to the fact that it worked with Artifactory, builds all the technologies in our environment pretty easily, had the SQL integration, and has lots of bells and whistles out of the box.

Most of the items in Maven's favor were simply a function of its maturity and the fact that we are doing a lot of Java development. In the absence of Java, it would be somewhat useless due to the narrow scope of the tool. I can very easily see us moving to Buildr once the gap closes in functionality, and I think this is going to happen relatively soon (as in, within a year or so). Dan was telling me there is a version 2.0 of Buildr on the horizon, and I imagine with all the Railsing and JRubying going on that more people will be jumping on the Buildr bandwagon as they look for a great build tool written in Ruby to supplement their Ruby-based development.

Since there is an easy migration path to Buildr from Maven, I don't have any concerns about a switchover in the future. All in all, it gives us a nice option to keep in our back pocket if the Maven situation should end up backfiring on us.