phew !

A good friend of mine sent me this picture of his desk at work, located a good 50 km south of Munich.

We all know that the higher the office temperature, the lower the office productivity, so i wonder why some employers just refuse to shell out 400EUR for a decent airco - knowing that they are likely to lose more money overall because of the reduced productivity !

Anyway, Thomas: perhaps you can apply some of the tricks described here to keep your head cool while coding away !

Manipulating Continuum’s internal database

If you’re using Maven2 to build your projects, then chances are you’ve got Continuum doing your CI (Continuous Integration). At Cocoon for example we use it to manage the deployment of the daily snapshots to the Apache snapshot repository.

It’s still a bit rough on the edges though as far as usability is concerned, especially for larger projects. I once wanted to change the build goal for all our modules from the default “clean install” to “clean source:jar deploy” and was very disappointed to find out there was no global goal setting i could enforce all modules to use. One solution would’ve been to change the defaultGoal element in the root pom but that ofcourse impacts everyone else building Cocoon - not desirable at all.

As i didn’t feel to click my way through 180 modules (and do it again every time Continuum’s database is zapped) i decided there must be a more clever way of handling this. So I figured i would have a look at Continuum’s internal database, hoping to be able to do a quick “update BUILD_DEFINITION set goal=’clean source:jar deploy’. Continuum uses Derby as internal database, so Eclipse + WTP is all I needed to start exploring:

  1. Make sure Continuum is not running
  2. Open the Eclipse Database Explorer View
  3. Add a new Derby 10.1 connection
  4. Point the database location to $CONTINUUM_HOME/apps/continuum/database
  5. Point the class location to $ECLIPSE_HOME/plugins/org.apache.derby.core_10.1.2/derby.jar if you don’t have the driver handy somewhere.

Your screen should now look something like this:

Now connect to the database. You’ll see a few familiar names in the table list :

The first table is called BUILDDEFINITION (so i wasn’t too far off !) :

We’re interested in updating the goals argument, so all you now have to do is create a SQL Scrapbook page and run it :

As far as i know, this is the easiest way of doing bulk updates to build definitions in Continuum. There is one caveat though: you need to have physical access to the database directory.

In one of my next posts i’ll discuss a way of achieving the same result without needing physical access to the database.


a.k.a the maven bug of hell, basically boils down to this:



If you have this in your pom then hibernate 3.1 will not be passed on transitively anymore because you’ve excluded it on another dependency. This can lead to all sorts of seemingly random behaviour, so beware when you start excluding dependencies from other poms !

As a workaround, you should exclude the unnecessary dependencies in the child pom rather than on the dependency directly.


If you’re the person that likes to stun your audience with a bit of eye-candy during presentations: OmniDazzle .