For a while now I’ve been meaning to get Hudson installed and running but what with one thing and another I’ve always put it off (I put it down to being a lone developer). What with everything else going on things like Hudson get pushed to the back of the queue all the time even though I’m fairly sure they’ll help. Well today I decided to do something about it.

I’ve actually had Hudson installed for a while but I’ve not really used it as I ran into some problems with the configuration and didn’t have the time to fix it. The problems were all due to Maven and mostly boiled down to it not being found by one process or another.

See the “Fixed It!” section the ramble below isn’t the simplest thing that could work.

The image here shows the configuration that I eventually ended up with. I don’t understand why but in order to get the builds to work I had to install Maven manually (into /data/apache-maven in my case) and configure it under Maven 3. In order to get the Sonar integration working I had to add Maven under the Maven section (which I called Maven 3 (Auto) so I could tell it was different. The Hudson installed Maven 3 then appeared under the advanced settings for the Sonar task in the build configuration. The auto-installed Maven doesn’t appear in the build section of the configuration though.

As I said I don’t understand why it has to be configured this way but it’s what works for me. The failure I was getting because letting Hudson auto-install a version of Maven was:

Cannot run program “mvn” (in directory “/some/path/workspace”): java.io.IOException: error=2, No such file or directory

Basically the problem was that the build process was using the full path to the Maven executable but the Sonar task was expecting Maven to be on the path. I tried numerous different ways to get Maven on the path but without much success. If you dig around for this error message you’ll find a fair number of people reporting it for various different versions of Hudson. In particular there is this bug report that seems to be exactly the problem. Sadly it was closed as could not reproduce. I actually suspect the problem is more that I haven’t properly read the manual yet, perhaps one day I’ll get the time…

Fixed It!

As I was several versions out of date with Hudson I decided to do an upgrade. As there is now a good Ubuntu package available for Hudson I also decided to switch over to the pre-packaged version which meant a fair big of reconfiguration. Guess what, I hit exactly the same bug as I described above – no matter what I did I couldn’t seem to get Sonar to work.

After much investigation here’s what’s wrong. Hudson comes bundled with a version of Maven 3 that it uses to perform the builds. It does this by issuing a full path to the bundled Maven executable. The Sonar plugin, in contrast,  switches to the workspace directory and then issues “mvn …blah blah…”. In other words the Sonar plugin is expecting Maven to be on the system path. This threw me because the Sonar configuration in the project is set to inherit the version of Maven the main build process is using

The only way I could see to fix this was to manually install Maven 3 (using the Ubuntu package) and then add a settings.xml file to the Hudson users .m2 directory (a manual install of Maven would also have worked but this is probably the simplest solution). Now when Sonar is executed it uses the system Maven and settings.xml rather than the bundled Maven and settings.xml. This isn’t ideal because it means the configuration will need to be done in two places all the time but it does work.

Another possible solution to this problem would be to symlink the bundled mvn executable into /usr/bin and then add a copy of the settings.xml file to the .m2 directory. This avoids the problem of having a completely separate mvn but might fail in strange ways when Hudson is upgraded.