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.