«« RadRails Snares New Committers Collaborative Documentation for Eclipse? »»
blog header image
Building RadRails with Ant

RadRails was different enough from Durham that the custom Ant build scripts to build their Rich Client Platform (RCP) products are starting to diverge. I don't see a problem with that -- it will be easier to maintain both that way.

One of the neat things I wanted to do with RadRails was build it with the Eclipse 3.2 platform plugins as well as the Eclipse 3.1 platform plugins every single time the build machine does a build. With the Ant scripts we can package standalone versions of RadRails based on either 3.2 or 3.1 and for Windows, Mac OS X or Linux.

Backwards compatibility with 3.1 is important because we want to make sure that RadRails still works on the stable 3.1.x branch for people that still have 3.1.x and use the update site to get RadRails.

Right now the build just makes sure that RadRails compiles under both 3.2 and 3.1. That's the absolute minimum smoke test, since code that can't even compile can't be packaged. Later on I'm going to add projects, packages and Ant support for a unit test suite and run that as well with each build.

The tentative plan is to offer the nightly and/or integration builds to the public as well, so that people can test 'beta' builds before we make releases.

When Eclipse 3.3 comes out, I'll add it to the build scripts and continue to build 3.1 as long as we offer backwards compatibility to that version (notice we don't bother with 3.0, should we?).

I'm still working on getting the nightly(N) and integration(I) builds going on the SourgeForge.net compile farm. Once I can login with sf's SSH key setup I should be all good as long as the build machine has Java 1.4 and cron.

Some people have asked me why I'm doing all of this build and test work. Am I still a Java+Eclipse+RCP developer? Of course, that's what I enjoy most. In RadRails' case I saw that I could contribute with the build/deployment experience I have from other RCP projects and improve its quality and stability. This is important to me because use RadRails for my Ruby on Rails work.

Sometimes you have to do things you don't think are super fun to ship a quality product. That's what software development is all about, right? OK, maybe Ant work isn't so bad. :) Deployment is an interesting, necessary and sometimes complex part of software development. Projects like this give me more of an appreciation for the hard work that software build engineers do.

Posted at June 22, 2006 at 08:25 AM EST
Last updated June 22, 2006 at 08:25 AM EST
Comments

Is Eclipse changing the plugin architecture for every minor version number change?

I thought that they only changed the arch. for every major build. Has that idea been thrown out the window, or is it something else?

» Posted by: Jim at June 22, 2006 10:40 AM

It's not the plugin architecture that changes, it stays the same within the 3.x major version.

Eclipse 3.2 is backwards compatible with 3.1, meaning that plugins written for 3.1 should work on 3.2. The problem is if RadRails uses new 3.2 classes that aren't available in Eclipse 3.1.

These Ant scripts will build both versions of RadRails, and make sure we're not using any 3.2-specific classes.

When we drop support for 3.1, then we can use classes that are only in 3.2+.

» Posted by: Ryan at June 22, 2006 10:55 AM

Ryan are you using the PDE automated build framework and then running it with Ant or your own home brewed setup? I've had issues getting the PDE build stuff to work with all of its callbacks and issues calculating plugin dependencies.

» Posted by: Scott Delap at June 22, 2006 01:20 PM

Hi Scott,

I'm using my own home brewed setup. Both the Durham and RadRails versions of it are open source, so you can check out the code if you like. In those project's source code repositories, you'll want to look at the build-* and platform-* projects.

The main reason I wrote my own Ant build scripts is because I wanted to control when and how unit tests were run, do code coverage (and instrumentation) and make testing and coverage reports.

They also let me completely control how the deployment packages for each platform are made, which files to include, etc.

The downside of my Ant scripts is that there is a little bit of manual work and duplication to get them to stay working (ie. listing all of the Eclipse plugins for the compile-time classpath). The upside is that they only depend on Java and Ant to work, not any special Eclipse tasks.

» Posted by: Ryan at June 22, 2006 02:10 PM
Google
 
Search scope: Web ryanlowe.ca