Sam Newman's site, a Consultant at ThoughtWorks

Archive for ‘July, 2005’

I’ll be at Open Tech 2005 on Saturday, as it looks interesting and its damn cheap (five of your UK pounds). Topics include blogs, copyright concerns, webservices, and the offical launch of’s developer network – aimed at providing ways to open up BBC’s content so Joe public can program a webservice for it or something. Most importantly it starts at the highly civil hour of 11:30am.

If you’re coming along I’ll be the skinny geeky guy with an under-developed social life and too many gadgets. I should be easy to spot.

Way before I started looking at a cruise control plugin for trac, Tammo van Lessen had been developing one of his own. Tammo’s solution uses XSLT to parse the cruise control logs – and it looks very similar to the cruise reporting application as a result. The big added benifit of course is that it integrates with trac (so no need for a servlet engine to display your logs). The current plan is that myself and Tammo will try and merge our efforts at some point, but until then I recommend you have a look at Tammo’s excellent work if you’re currently using trac and CruiseControl.

It’s OK everybody, there is no point comparing Django and Rails, Obie has it sorted:

There’s one problem dude… No matter how good Django is, it isn’t written in Ruby.

You see, that’s what so great about Obie – he can deliver a balanced, reasoned comparison without letting language politics get in the way.

Package dependencies in Pasta

Package dependencies in Pasta

Today on my current project I had to spend some time creating a client JAR file for use by downstream systems. I needed to keep the JAR as small as possible, with (more importantly) no external JAR dependencies.

There are tools out there for dependency analysis, such as IBM’s Structural Analysis for Java (aka Smallworlds), Compuware’s Pasta or the open source JDepend. As nice as these tools are, they are for analysis and the gathering of metrics. As I’ve mentioned before, unless ‘good metrics’ are in some way enforced by the build process, it becomes very easy for even automatically gathered metrics to be ignored.

JDepend can be run via Ant, but just like Emma or Findbugs the information gathered is used for reporting purposes – it is not capable of failing a build because someone has introduced an invalid dependency between packages.

Japan is a tool which comes with an Ant plugin that will fail a build if your code violates the allowed package dependencies. For example, our downstream systems only need to use classes in the client package – I don’t want to have to include any other code in the client JAR file. So in a Japan config file I place the following code:


Now if any of the classes in client include any other packages in my codebase, the build will fail. It’s important to note that Japan requires that you define all your dependencies at the package depth you define (the package-depth="4<a href="" <2>> means that all source code in and below will be checked) – so for example if our gui package depended on util and client, I’d have to add the line:


By defining these configurations you can quickly discover circular dependencies) – for example if to get the build passing you find yourself defining something like this:


You know something is up. The other thing I like about Japan is the fact that because I can now enforce sensible package dependencies, I feel better about spending some time cleaning our packages up, safe in the knowledge that we won’t backslide (assuming no-one goes and sticks everything in one giant package of course). There was one little problem I had though – I had to disable transitive dependency checking as it caused a stack overflow error, but I think once we remove our existing circular dependencies that should sort itself out. I still of course like to have tools like Pasta to help me define acceptable inter-package dependencies, but I feel much happier having Japan in the build just in case I start getting sloppy :-).


“It’s all gone quiet over there”
“You’re going home in a rather disappointed ambulance”

This has been a public service announcement from the Smug Londoner Party.

Don’t they know this is the UK? If you’re over here letting off fireworks, you bloody well better be burning the effigy of a Catholic, and it better be November.


The Cruise Control plugin in action

Click for larger image

I’ve long been a fan of the python-based ticket tracking/wiki/subversion browser, trac. It manages to integrate subversion changesets with tickets quite simply – go to a changset page and you’ll see the edits; go to a ticket and you can see all changesets that apply to the ticket. On top of that you can use wiki syntax in your subversion commit messages (or anywhere for that matter) – to my mind trac is perfectly capable of doing away with the need for separate systems (certainly on my next project I’ll be recommending trac over a Jira/Wiki/ViewCVS or FishEye combination).

I’ve long been a critic of the CruiseControl reporting application. Whilst the underlying build-loop is fairly solid, the separate reporting application lacks features, is slow, and is in need of some UI love. With the new 0.9 development, edgewall have added a plugin architecture. Ditching the CruiseControl reporting application in favour of a system which is fully integrated with your changset and ticket monitoring system seemed like an obvious next step, so I spent the weekend working on a spike to do just that.

The overall aims of the plugin are:

  • To show CruiseControl builds in trac’s timeline, alongside wiki edits, ticket changes and SVN modifications.
  • To have a page for each build which can be linked to using trac’s wiki syntax as with tickets and changsets
  • The build page should show the same information as the existing reporting application
  • It should be faster than the existing XSLT-driven reporting application
  • When looking at a ticket, you should be able to see what builds apply to it (this for me is the real killer feature)
  • Going forward, the plugin should work with other Continuous Integration tools (top of the list will probably CC.Net)

    As you can see from the above image, integration into the timeline was fairly easy. Currently when the timeline is requested, my simple SAX-based cruise log file parser pulls out the relevant information. The next step here is to place this information in trac’s built-in SQLite DB (which should take care of the ‘being faster than XSLT’ requirement). I may even create a plugin for CruiseControl so it can ‘push’ build results to trac in a cleaner, more efficient manner than parsing the XML files (a simple REST webservice for trac should do the job here – trac already seems pretty RESTful). A page for each build is probably my next priority though. The only unknown at present is whether or not I can integrate the builds into the ticket view – the plugin API doesn’t seem to expose any hooks here, but I’ll raise the issue with the trac developers and see what they think.

    Anyway, feedback on what CruiseControl users would like to see by way of features would be appreciated – as would anyone willing to test it. As I said, it is a spike right now – I’ll probably start reimplementing it tonight – but you’re welcome to play around with what I have right now (if you have the latest version of trac from subversion, installing the plugin should be a breeze).