JRake: Build, Test, and Deploy Java applications without XML

Posted by Rob Thornton on Dec 18, 2006

Sections

Process & Practices,

Development,

Operations & Infrastructure

Topics

Java ,

Build systems

Tags

JRake

JRake is the latest entry in build tools for Java that is based on a scripting language. JRake leverages JRuby and the Rake build tool for Ruby to make building, running tests, and deploying web applications quick and easy.

Matt Foemmel was looking for a tool that fit two criteria: be based on a scripting language and run on the Java platform. The three tools he investigated are make, ant, and rake. Neither make nor rake run on the Java platform, and he says this about ant:

it's not based an existing scripting language. While it's true that you can drop down to Java and do complicated things by writing your own tasks, the context switch is pretty jarring. One problem is that you have the extra step of compiling your tasks before you compile your code - and therefore your build script now needs a build script. But the real issue is that Ant tasks only let you put custom logic at the task level, not at the level that actually manages the tasks. For example, if you want to define some dependencies between projects in one place, and use that to drive a bunch of build steps for each project, you're in for a tough time. It can be done (we used XSLT to generate ant scripts on one project) but it ain't pretty.

His first step was to get JRake to compile his Java code. He provides a complete "Hello World" project available at: svn://svn.foemmel.com/blog/jrake/compiling.

Step two was to get JUnit tests running from JRake. He did that and went a step further than just running JUnit tests as he wanted to avoid any unnecessary startups of the VM. To that end, he created Interactive JRake which sits in a loop prompting for targets. Once again, a sample project is available, at: svn://svn.foemmel.com/blog/jrake/testing

The third step was to provide a way to run the application. He describes his goal for this as:

Assuming our application is web-based, the obvious solution is to wrap it up in a war file and deploy it into a container. But as anyone who has worked on a large project knows, creating and deploying war files can be a painfully slow process. Our original mission was to cut as much time as possible off our edit-compile-run cycle, so this clearly isn't the right solution. (We will need to generate war files at some point, of course, for deploying into production environments, but we'll save that work for another day).

...What we really want is for Java code to work the same way that dynamically typed languages do: you change your code, hit "save", and view the results in the browser.

To meet his goal he set up a Jetty server to act as a proxy which calls out to the JRake script which results in being able to make changes in the IDE and immediately see them in the browser. The sample project is available at: svn://svn.foemmel.com/blog/jrake/running

1. Back to top

   What about Raven ?

   by Andres Almiray

   What about Raven (raven.rubyforge.org/) ? it is already in version 1.1.2, there is even a previous article on this site about it www.infoq.com/news/2006/11/raven-build-java-wit...

   Reply

2. Back to top

   Re: What about Raven ?

   by James Waldrop

   Capistrano, too. Which admittedly isn't so much a build system as it is a deployment system, but it's probably a lot more interesting to Java devs than pure Rake.

   Reply

3. Back to top

   Raven, JRake and AntBuilder

   by Aslak Hellesøy

   I have written up a brief comparison of Raven, JRake and AntBuilder in my blog.

   Reply

4. Back to top

   Need more declarative capabilities

   by Ilya Sterin

   I can do the same with Perl or any other language. Just because there are libs to make the job easier, doesn't make it a robust tool. What is really needed, is something similar to maven or ant and is easily extended with any scripting language JRuby, Jython, etc... Hopefully JSE 6 will allow that to happen, with it's extension capabilities for DSLs.
   
   Either way, no one wants to script their build from scratch. Maven provides a declarative capabilities for describing your project and allows it to make assumptions. Struts provides a more flexible (though sometimes this flexibility is an overkill) environment. What is needed, is a way to say embed scripts within the build files, for things that are not naturally done in xml declarations (logic). The only big issue with ant and maven is how hard it is to perform any activities that require programming logic, loops, conditionals, etc...

   Reply

• Older >