Why use Buildr instead of Ant or Maven?

Buildr looks like an improvement over Ant for people who do not need or want Maven and/or dislike XML.

I use Buildr partially because it has the best Scala support of any build tool, but also because it has all of the dependency-managing goodness of Maven and then some. For example, Buildr makes it almost trivial to use artifacts which aren't in a repository. You can specify the URL of a zip or tarball to download, out of which Buildr will extract the relevant JAR file and install it into your local repository. For libraries which are in a Maven repository, Buildr is by far the easiest way to install them on your project's classpath. For example:

repositories.remote << 'repo1.maven.org/maven2'

define 'my-project' do
  compile.with 'commons-cli:commons-cli:jar:1.0'
end

After installing that in your buildfile and placing your sources in src/main/java, just run:

$ buildr

Buildr will take care of downloading the Commons CLI dependency, compiling your sources and running all tests (if any). As an extra bonus, it will perform all of these tasks quite a bit faster than Maven would have (really, Buildr performs exceptionally well).

What really puts the icing on the cake is how easy it is to define ad hoc tasks. Buildr is built on top of Rake, which means that anything you can do with Rake, you can do in exactly the same way with Buildr. For example, let's say that I wanted to define a task to generate documentation for my project using ReStructured Text. Buildr doesn't have a built-in task for that, but I can easily define one of my own:

define 'my-project' do
  task :rst do
    system 'rst2html', _('README.rst'), _('README.html') \
      or fail 'Unable to invoke rst2html.'
  end
end

With this, I can invoke the following from any subdirectory of the project:

$ buildr my-project:rst

Buildr takes care of canonicalizing the paths (that's what the mysterious _ method handles). I could even change things up a bit using Rake file task magic so that the rst task only runs if the README.rst file has changed since the last rebuild:

define 'my-project' do
  file _('README.html') => _('README.rst') do
    system 'rst2html', _('README.rst'), _('README.html') \
      or fail 'Unable to invoke rst2html.'
  end

  task :rst => [ file _('README.html') ]
end

It's hard to overstate just how powerful and useful this is in practice. I used to be a die-hard Ant user, not because I liked the tool, but because it was standard and I had yet to see anything better. Maven was (and is) too complicated and too restrictive. Imagine trying something like the above in Maven. You would have to write an entire plugin, just for that!

The only problem with Buildr is the fact that it isn't very widely used, and so a) not a lot of people have it installed, and b) not a lot of people know how to use it. It's not a difficult tool, but it's harder than Ant if that's what your dev team already knows. Fortunately, both of these problems are easily remedied given enough time and exposure.

If you think about it, the question isn't "Why use Buildr?", it's really "Why use anything else?" The advantages afforded by Buildr are so substantial, I really can't see myself going with any other tool, at least not when I have a choice.

I've used Buildr for quite some time and believe me, it's an order of magnitude or two less painful than Maven. Copying a file is cp, not 20 lines of XML you have to spend 4 hours to get right. We're using it on a fairly big and complex build, in Apache ODE. Check it out for yourself (that's the whole thing):

github.com/apache/ode/blob/trunk/Buildfile

We used to rely on Ant, with a fairly extensive set of scripts. It worked but was expensive to maintain. The biggest mistake afterward was to migrate to Maven2. I could write pages of rants explaining all the problems we ran into and we still ended up with thousands of lines of XML. Check these two excerpts:

github.com/apache/ode/blob/aa9743cd981a4d2f9ea8668c3283cc1cb6b08bcf/pom.xml github.com/apache/ode/blob/aa9743cd981a4d2f9ea8668c3283cc1cb6b08bcf/axis2-war/pom.xml

$ ack -g "(build|pom).xml" | xargs wc -l 4652 total

By my count that's 4652 lines against 698 and our build was much simpler back then, so the comparison isn't even completely fair to Buildr.

So which one would you rather write/read/maintain?

Well first there was ANT, and that was too procedural and XML based instead of a real scripting language.

Then there was Maven. That was too complex.

Then Ruby got popular, so this is an attempt to make a better build process that is as powerful as Maven as using a DSL based on Ruby to not make it complicated. It's all the latest rage (DSL's in Ruby) in some circles.

You didn't mention Ivy, which brings some more Maven functionality to ANT.

The nice thing about Java is there are so many options. The bad thing about Java is there are so many options ...

But anyway, the core answer is that Buildr attempts to solve the build challenge with a different technology approach (a DSL in Ruby) something that doesn't exist in another Apache project.

I've moved our code base to buildr, and overall, am much more pleased than the XML-based tools.

Experiences:

1. It's taken me a while to get the buildr workflow when I need to customize it
2. Figuring out what part of the API documentation does what is still a little mystifying for someone who doesn't really know Ruby intensely
3. #1 and #2 didn't matter at all: I was able to customize EJB and Jarjar deployments, change the TestNG workflow, etc, without really feeling strong about the tool or the ruby language.

That's still the strongest sell: it builds everything I need, and as I've needed more, I just got things working without a lot of fuss. Haven't done C-based builds, but we do preprocess markdown into a documentation site, for example. And we just integrated that tool with very little code.

With maven and ant, I always ended up making substantial external scripts. With buildr, it only takes a pretty minor amount of ruby knowledge for you to hack together a pretty workable system. And the more you learn, you will have far, far less code.

I never even got close to creating an ant or maven plugin - it was never worth the time.

It's not hard to write a plugin, but it is a lot of overhead to wrap a one-shot action as a plugin. It is also harder to maintain (need to edit the plugin file, build, package, deploy instead of just changing the task code in the buildfile)

With BuildR, your build files are written in a real language (you can use variables, methods, loops, containers), which is needed because building a product requires custom logic (code). The myth that Maven tries to sell is that it is all just declaring what you wants (via properties) and a "maven" creates everything for you. You need your own code.

Because of the fact all the modules are defined in one file, it allows to easily share common data (artifact names/versions, custom methods, layouts etc.) between projects (contrary to mavens inheritance or ant's import)

After using BuildR for some time now I can say it is very well designed (but not over-designed as Maven is)

One more thing, that people may not consider is that because of the openness of Ruby I found I can fix bugs in BuildR by rewriting the buggy method (usually very short) in a file checked out with the project. This means I'm not biting my nails waiting for the next BuildR release. I just submit a bug, fix the bug and go on.

You are welcome to check out my Java build tool designed with multi-module support as the primary goal https://github.com/hackingspirit/Lattice .

Overview: In Lattice build files are written not in XML, but in the Python language. The benefits are much better readability and powerful imperative build scripting supported by Python. For multi-module projects. Lattice uses topological sorting to decide the correct order to build each module. It’s also planned that Lattice will analyze the module dependency to determine how the module compilation can be parallelized. Lattice’s source code is extremely lean, currently it consists of about 500 lines of Python source code. Lattice supports generating Eclipse projects from the build files.

See also this thread on the buildr mailing list on buildr vs ant or maven.

And btw., I'm using buildr since then for my private projects and love it - it really provides best of both worlds (declarative/mvn + imperative/ant).

I'm also just in the process of converting a multi module ant project (using ant script library) to buildr and the build is getting much, much simpler.

The positive side effect for me as a java user is that I learn a little ruby, and that's easy but lots of fun... :-)