Last summer we evaluated various Java build tools. Our goal was to migrate away from our legacy build tool, a custom Java extension to Ant that uses Eclipse .classpath and .project files to determine dependencies.

The de facto standard for building and packaging any sizable project in Java is Maven. Some of us are not fans of Maven’s declarative xml and black box behaviour that sometimes requires extensive study.

More importantly, the build tools of the future will have a dynamic / scripting language as their underpinning. We see this already with Rake (Ruby), Scons (Python), and Buildr (Ruby), though each is still clunky. We’re also seeing this with deployment frameworks like Chef (Ruby) and Fabric (Python).

Maven’s GMaven Groovy integration looks promising, but it’s been looking promising for years now. We also lean towards Python and Ruby rather than Groovy. In the end, Maven was our second choice.

Our existing build is needlessly complex; there’s some 30 projects all in one workspace, encompassing our 3 main product lines. The legacy builds on CruiseControl take 2 – 3 hours; they rebuild everything and run all tests. One of our goals is to split groups of projects out, since the lower layers only need to be rebuilt occasionally. This would also let us split our Mercurial repository from the one giant repo that we have into smaller product / project specific repos.

We decided on Buildr since it has Rake / Ruby underpinnings, seemed easier for us to transition to without restructuring our existing source code, and various other reasons (see the comparison doc linked below).

The project to transition to Buildr was funded part time for a few months and we made a lot of progress. We’ve been to the point where we use Buildr extensively for local development and TeamCity continuous build / test cycles.Unfortunately we have not yet finished the final switch over to Buildr for production builds, which is the last barrier to splitting the projects / repo.

We were able to cut our local workspaces down to ~13 projects from ~30, which greatly sped up development. We also offloaded all of our test running to the TeamCity build machines, to avoid the lengthy pre-push local test runs that we did previously.

TeamCity gets us initial build / test results in about 5 – 10 minutes now, which is a huge win.

The time savings averages 1 – 2 hours per developer per day across our main engineering group. This cost savings made the investment in the project possible.

Overall we’re pleased. Buildr seems to provide all the Java-ness that you would need if you started from scratch writing a Java build tool with Rake. There are a few confusing black boxes, which is frustrating since it’s one of the reasons we avoided Maven, but as with most tools once you’re in the swing of it

Thanks for reading!

Michael Lossos

Shares 0