(I took this post out from the ‘shelf’, it was lying here as a the draft for more than two years, anyway, in case it might still be useful, I publish it today :))

Introduction

So, due to the recent build structure change of the main project I work with (Bennu), we ended up with having to deal with ~61 Maven modules, and trying to minimize the changes to the workflow process of the developer. That meant that we wanted to trigger a deploy on Maven of the module’s JAR/WAR, when its code changed, with a simple SCM commit.

Architecture

So, we are still using SVN  for the SCM. (I’m lobbying for Git, and git-flow, which actually is great to tackle some issues we have with the maintenance tasks, and I have been actually profiting from the use of git-svn for quite some time now on my current workspace [yeah, we ended up using it :)])

We have two SCM repositories, a public and a private;

We used an old version of Hudson as a continuous integration (CI) tool (updated to latest version of Jenkins), to make sure the committed code was minimally ok;

We use Sonatype’s Nexus as a Maven repository [although we could have used jenkins itself, I later discovered];

The SCMs, Maven rep, and CI tool are all on the same server (although Jenkins offloads all the work to a more capable server);

We now have ~61 Maven modules to manage all of a sudden (we changed from the old, ant and black voodoo based, module system, to the popular and very handy maven);

Solution

So, we figured that the best would be to have Jenkins deploy to the Maven repository all of the commits that were made, being the committer responsible to update the module’s pom, and in case something went wrong with the compilation of that module, or with any of its dependencies, an email would have been sent warning everybody.

The challenge was to make this automatic i.e.: Having Jenkins sensing the Maven modules amongst other un-mavenized source code, and recognize changes to them on each commit, so that Jenkins is actually able to deploy to the Maven repository the existing modules, and also new ones.

For that job, the solution I came up with was a somehow elaborate SVN hook, that relies on  a couple of conventions, and that creates a new Jenkins job, in case a job doesn’t yet exist for that Maven module, and triggers a build of it upon changes in the SCM of that project’s code.

So, without delay, to the SVN Hook in question:

If you have any comments/feedback, let me know