A Small CruiseControl Fix, and a Critique of Spring

I quite like the new Dashboard that was added to CruiseControl last year. It has a certain style that makes it appealing to the end users who may be watching the build status, and is a step up from the old reporting JSPs. Until today, I had never really looked into how it was implemented.

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.