Installing Apache Buildr on OS/X 10.6

Posted by Mathias in [scala]

20 Aug 2010

For my first larger, Scala-only project I just set up a brand-new project space.
Normally all my projects have an IntelliJ IDEA project structure set up for the day-to-day work. However, I usually also include a paralleling project spec for some build system for creating the final deployment or distribution artifacts. For all my Java projects this is (and always has been) an ANT buildfile. ANT is simple, everyone knows it, everone has it, it works, no further explanation required.
Of course, an ANT buildfile is just pure ugliness. It’s XML. Written by hand. (I know IDEA can create an ANT buildfile automatically, but the end-result is even more verbose and simply not useable for me as basis for further customizations/extensions.)

So, upgrading the core language of my developments from Java to Scala in order to reap all kinds of benefits in the “beauty/conciseness” area brings along the wish to do the same with the build system. My needs in this area are simple: Support me in building, testing, packaging and deploying my application with as flat a learning curve as possible. If the specification of my project is concise and extensible, I am sold. Not working on huge systems with a great number of ever changing dependencies I really don’t need all this complicated, Maven-ish transitive dependency, “POM.XML”, repository, signature mess. If it is supported, fine, but please don’t get in my way of simply defining a few JARs in directory “xyz” as required libraries.

A quick statistics on build systems used by existing Scala projects seems to yield a clear favorite: SBT. However, after having played around with SBT for two hours I gave up. I have to say that I am somewhat disappointed. The documentation sucks: It is not up-to-date, incomplete and lacks clear examples for common use cases like a project with multiple sub-projects (aka modules). Additionally, IMHO, the internal Scala “DSL” SBT uses for project configuration is just as bad as its documentation. Scala is a great language and can be a base for excellent internal DSLs, if they are well-designed. However, looking at existing SBT project configurations (e.g. the one for Scalatra) I find them verbose, un-intuitive, hard-to-understand and generally much to complicated. Additionally SBT clutters my project space with “funny” directories like “/project”, “/src_managed” or “/lib_managed”.
Why do all these Scala projects put up with this?
I guess the reason is that they were started in times where there was practically no IDE support for Scala. Sitting in a plain text-editor I can see the need for a more involved build tool efficiently managing the continuous write-compile-test cycle. However, since IDEAs Scala plugin does that job for me (and I am not saying that there isn’t still some room for improvement) there is really nothing left to sell me to SBT.

With ANT, Maven (see above) and SBT out of the way there seems to be only one serious contestant left: Apache Buildr. It uses an internal ruby DSL for project specification and generally appears much cleaner than SBT. After having managed to get it up and running on my machine and having played with it a bit I think I will go with it for the time being. However, the installation was a bit more complicated than expected, so here are:

The instructions for installing Apache Buildr 1.4.2 on OS/X 10.6 Snow Leopard for using it to build Java or Scala applications running with Java 6:

  1. Install XCode
    If haven’t already installed XCode do it now. It provides everything required for properly building unix tools on the command line.

  2. Install RVM
    Apart from being generally an excellent tool for everyone working with ruby there is a specific reason, why you will want to use RVM. Java 6 is only available in 64 bit on OS/X 10.6. For Buildr being able to interface with 64 bit Java it needs to run on a 64 bit ruby version. The only way to get a 64 bit ruby version in OS/X is to compile it yourself. Compiling ruby is extremely easy with RVM.

  3. Open a shell and run rvm install 1.8.7
    This will make RVM download the latest MRI ruby 1.8.7 version (patchlevel 302 at the time of this writing), compile it with 64 bit and install it. Note that this does not in any way affect your “system ruby” (the ruby version coming with OS/X).

  4. Create a gemset for your application with rvm gemset create '{app-name}'
    The {app-name} should be the name of your application.

  5. Switch to the newly created gemset with rvm gemset use {app-name}

  6. Run export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Home
    If you have JAVA_HOME already set this is not required.

  7. Run gem install Buildr
    This will download the latest version of the Buildr gem (1.4.2 at the time of this writing), compile its native extensions and install it.

  8. Change into your app directory and run echo 'rvm 1.8.7@{app-name}' > .rvmrc
    This creates a project .rvmrc, which causes RVM to automatically switch the to right ruby and gemset when you cd into your application directory.

Your Buildr installation should now be ready to go.

Note that you could also run Buildr with jruby with a little less installation effort. However, jruby has a much longer startup time than MRI ruby, something that will quickly annoy you once you work with Buildr a bit more intensively. There is a way around that using nailgun, however the MRI version achieves the same performance with less complexity.

So long,

Update (2010-10-12)

The above setup, with Buildr running against an RVM ruby, will work nicely but not issue any Growl notifications. The reason is that RVM rubies do not have RubyCocoa installed by default. After correcting this by following these instructions the Growl notifications will work as expected.

View Comments