My problem today was that the Dashboard does not show raw build output by default (it will show plenty of reports and other bits and pieces from an Ant build). In my case, I’m calling an external build tool (not Ant) using the CC <exec> builder, but there is no way to actually see the output.

A quick look at the dashboard-config.xml file showed that there appeared to be a simple way to add another tab to the build display using classes from the Widget package. Looking in the CC source code, I spotted a class called net.sourceforge.cruisecontrol.dashboard.widgets.AntOutputWidget, which despite it’s name, looked like it would display the build output for anything. I tried adding a reference to this class to the configuration. Sure enough, a new tab appeared. Unfortunately, it only ever displayed the text “No information for Ant Output”. Doh!

Googling about, I was able to turn up a message from Pete Doyle who had exactly the same problem. He had even submitted a patch to the CC mailing list, but it appeared to have been missed. I tried out his patch, and everything worked fine (after a few fine tweaks). While I was there, I created a new task in the CruiseControl issue tracker: CC-899. Hopefully, this can get rolled into the next CC release. Score 1 for open source!

However, the story doesn’t end there. Before I moved on, I just happened to glance at the documentation for subtabs. There is a strong note warning that these widgets are deprecated:

Note that the dashboard widget API is deprecated and will be replaced in a future version of CruiseControl. We strongly recommend developers do not create widgets using this API, as it will not be supported in the future.

I found this curious: I didn’t think the code for Widgets was that bad, what New and Improved implementation was replacing it? The answer was harder to work out than I expected.

The problem (as I see it) is that there is a relatively convoluted set of Spring configuration files joining bits and pieces together in hidden ways, and somehow using a heap of Velocity templates to generate the UI. My issue is that although the code appears to be quite solid and well factored, the configuration that wires it all together is quite opaque. Because it is Spring configuration (programming by XML), I lost the ability to easily navigate the code using the IDE. It was back to searching for snippets of text, and then looking up the referenced classes.

XML is not a good language in which to write programs. I don’t mind Spring in small doses, but I’ve been burnt a number of times by very large and unwieldy Spring configurations that wire together lots of small pieces in such a way that it’s very hard to get a view of the important features. Scoping, encapsulation, IDE integration: trodden over in a very haphazard way.

I’m all for dependency injection and inversion of control, but I definitely think that most of that can be done more efficiently in code. There are a few posts floating about on the same subject. Here are some of my favourites:

• Crazy Bob (inventor of Guice): I Don’t Get Spring
• Floating point: A Critique of Spring.

The first thing I did was to install Subclipse, which is not yet part of the main distribution (I wonder when that will be added?).

Next: test out a Java project. I tried setting up CruiseControl by checking out the project directly from the source repository. The project check out OK, but there were a number of build issues I had to chase up. Given that I’m going to be doing a bit more work with CC, it’s probably something for which I might be able to submit some fixes.

Finally, tried setting up a Ruby project. This was slightly harder than expected. I remember using the Ruby Development Tools (RDT) plugin a couple of years ago. However, when I visited the RDT website, it was pretty obvious that the project has become defunct, with no updates for quite a while. This is a broken link on the website pointing to a company called Aptana, who now provide a product called RadRails, which is a repackaged Eclipse set up for Ruby and Rails development. Given that I only had a number of smallish Ruby scripts to maintain, I didn’t actually want to download an entirely new IDE, and a stand alone plugin for Ruby development didn’t seem to be available.

I was finally able to find the thing I was looking for: it’s the Dynamic Languages Toolkit, which is actually already part of Eclipse Ganymede. All I had to do was from within Eclipse select the menu Help -> Software Updates… and select the “Available Software” tab. The option for Ruby development can be found in the tree by navigating via Ganymede -> Programming Languages -> Dynamic Languages Toolkit – Ruby Development Tools. Select the checkbox, click “Install..”, and it’s done.

Eclipse software updates dialog

On my first attempt at debugging, I had the following problem:

Debugging Engine not started
The 'Fast Ruby Debugger (ruby-debug)' is selected, but the 'ruby-debug' gem doesn't seem to be installed in the selected Ruby Interpreter (/usr/bin/ruby)

Change the relevant option in the ruby dubugging configuration screen, and everything working fine.

The AFP Renderer development team (that’s Pete and I) is pleased to announce the release of AFP Renderer 1.1.0.

This latest release can be downloaded from http://afp-renderer.sourceforge.net/download.html.

The important changes since the last release (1.0.2) are:

• added support for outline fonts
• added sample fonts with distribution
• added XML2AFP command-line utility
• added examples
• fixed rendering of tables removing double lines
• fixed rendering of tables in landscape
• fixed shading table cell problem in landscape
• expanded and updated documentation

Existing users should read the notes on upgrading the configuration in http://afp-renderer.sourceforge.net/configuring.html, as the structure of afp-fonts.xml has changed slightly.

For more information about the AFP Renderer, see http://afp-renderer.sourceforge.net/.

There’s nothing unusual about this type work, any developer working for a large corporation will do similar tasks. The amazing thing is that Pete managed to convince our management that donating this project back to the Apache Foundation would be a good idea. The result of this is the AFP Renderer project on SourceForge. In a fit of madness, I told Pete I could help out with creating the AFP Renderer Homepage.

The ultimate aim is to get the AFP Renderer source code integrated directly into the Apache FOP codebase. In the meantime, SourceForge has (yet another) project.