Raven: Building Java with Ruby

I haven’t been writing for quite a while now and that’s because I’ve been busy. I’ve been working on some sort of pet project: Raven. The idea is to use a really powerful language that can elegantly address scripting in build scripts: Ruby.

The good thing is I didn’t have to start from the ground up, Ruby already has two very neat and robust tools that helped me quite a lot: Rake and RubyGems. Here is how I leveraged them:

  • I’ve used RubyGems to solve the dependency problem. Java jars are wrapped in a Gem. That’s all. From there RubyGem does all the job of looking up needed dependencies, managing local and remote repositories, installing the dependencies, handling the different versions.
  • I’ve used Rake to solve the build script and task problem. It makes it easy for you to create a build script with different tasks an tasks prerequisites. And from there, hey, it’s plain Ruby!

Now you could be wondering what Raven is doing after all, if all these features are already provided. Here we go:

  • First it does all the wrapping work, importing either your local Maven (1 or 2) repository into the local Gem repository or building a remote Gem repository. So if you’re already using Maven you can get started really, really quickly. If you don’t, you’ll just have to setup your own repository, Raven makes it easy.
  • Second it manages your dependencies. Or more precisely it talks to Gem to check where your dependencies can be found and install them locally. These installed Gems will then be used to build your classpath.
  • Third and finally, it provides a set of already defined Rake tasks for the most common operations. Things like compiling, building a jar from your classes, javadoc, etc …

To illustrate, this is a simple “Hello World” style example of a rakefile that could be used to build a project:

require 'raven'
require 'rake/clean'



dependency 'compile_deps' do |t|
    t.deps << [{'commons-logging' => '1.0.4'}, 'commons-pool']
    t.deps << ['commons-lang', 'wsdl4j', 'log4j']

javac 'compile' => 'compile_deps' do |t|
    t.build_path << "src/main/java"

jar 'ode-utils.jar' => 'compile'

The best part of it is it’s quite plain Ruby. So you can simply script your build the way you want to! No more XML fighting or plugin fiddling! So if you feel that this cool could fit your needs, just check it out!

P.S. This idea came during a lunch break with Assaf, we were discussing the pains of the different solutions in Java to get a build done, when Ruby had such excellent tools. So thanks man for your great ideas!


8 comments so far

  1. Andres Almiray on

    Hmmm, what is the point of turning a maven build into ruby code? xml hate?

    This looks like ant with dependency management, you need to describe each step of the build.

  2. mriou on


    Sorry for the late reply, I’ve been quite busy recently. So yes, the first reason is XML hate or more precisely XML being painfully awkward when it comes to building things.

    The second reason is that neither Ant nor Maven provide you an easy way to script your build. And my opinion about building is that it’s all about scripting,

    Finally I wouldn’t describe Raven as Ant with dependency management. You need to check out Gem and Rake a bit more, you’ll see that these tools are far more powerful than it appears.

  3. Labnotes » Rounded Corners - 32 on

    […] Get out of Jail, collect $50. Building simple projects with Maven 2.0 is simple. Building anything bigger than trivial requires pompous XML files where ten lines of code accomplish one simple task. If you’re lucky. The less fortunate have to create another project to build a plug-in they can use to build their existing project, and invent more XML grammars along the way. Then there’s the Maven Uncertainty Principle: some builds will work some of the time. So let’s trying something different. Matthieu is working on a build system for Java in Ruby, using rake and gems. Give it a try, let’s see if we can bring simplicity back to the Java world. […]

  4. Andres Almiray on

    I know what you mean, I used maven1.x for almost 2 years and “loved” scripting it with jelly. Now with Maven2.x that is no longer possible. I recently needed an Ant build and used Maven2 for dependency management and site building, it felt good but a lot of XML was needed, I think I now know why you started Raven.

    Perhaps my first reaction was visceral “Why Ruby if we have Groovy?”, but then why not create Graven to go along with Rails/Grails and spread happiness in both communities ? (ok, getting back to earth…)

    Good luck with Raven!

  5. […] Neat? Then you can easily write your Rake script to use these dependencies and build your java project using Raven’s java tasks. See my previous post about this. […]

  6. […] do like where Matthieu is headed with raven or Russel Winder is headed with gant, but I’d really like the two together: non-XML […]

  7. danoxlade on

    i get an error on os-x tiger when i do raven import:

    Not a directory – /Users/danoxlade/.maven/repository/.DS_Store (Errno::ENOTDIR)

    how can i fix this?

  8. Brent on

    I hate to rain on anyone’s parade, and so I won’t. What I will say is that I think people frustrated with Maven (especially 2) often argue the same point. It is simpler to script it (I’m a coder darn it – get out of my way). However, it seems that this argument is made out of ignorance of what Maven was designed for. Maven was created to factor out the scripting that people were doing. Yes, it is simpler for you to do your dinky task, but not for someone else to do your task (or understand it). By ‘building a build’, you have created two projects out of one – one is the real project and one is the build. Maven works very well within parameters it was defined under – if you are writing tons of XML, you might be trying to use Maven for something it wasn’t intended for. In my experience, I found that most of the problems I was having was in understanding the ‘Whys’ rather than the ‘Hows’. When I finally figured those out I kicked myself. I was trying to do what the tool was meant to prevent.

    The tool is meant to solve aggregate software issues. If you are running one or two projects, you probably don’t feel compelled to use this tool over one that allows you to directly code up your build (after all it is easier to understand conceptually). However, once you code for a while and have created 100s of projects that share dependencies and should share code, but don’t, or you have 100s of build scripts with varying setups and levels of quality, you’ll probably look for a tool like Maven.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: