The particular library was in the pom.xml dependency hierarchy but it was resolving to an earlier  version. Maven was switched to offline mode during the tests and I had never needed this version of the library before. This meant  that the local version of my maven repository did not have jar and maven emits it slightly unhelpful error. It would be better if it told us that it could not find the artifact and since its in offline mode, can't go and retrieve it.

There are two quick hacks. Add the library and version into the pom.xml and do a build. This will pull the library into your local repository and maven will be able to find it offline. You could also just take maven in the tests online by removing the goOffline() method call.

As for the cause of the issue, it stems from the way maven resolves dependencies from Arquillian in comparison to building. I had updated a library version, which now depends on the newer version of javassist. However, in considering all the other things within the pom.xml, maven brings it down to an earlier version when building.

However, the dependency resolution within the maven run through Arquillian considers a slightly different set of requirements and resolves to a later version of the lib which is not available.

Installing hudson / jenkins is easy enough. I deployed as part of a pre-existing tomcat6 installation so was as simple as popping the war file into the webapps folder. Tomcat automatically started it up without issues.

I chose to have hudson use /home/hudson as its home directory. Since I am running an ubuntu system, I added a line into /etc/defaults/tomcat6. There are various other ways of doing this but it was a quick fix for me.

You of course need to make sure the directory exists. I also popped in a .m2 folder from my home directory to save it from downloading all the various jar files and included a settings.xml file with appropriate configurations.

Hudson 2.2 uses maven 3 but I use maven 3 locally as well even though the projects pom files were built for maven 2. There doesn’t seem to be any issues with this setup.

First step is to create a new job from the home page. This asks for which type a job you want to create. If you use maven and a standard source control, it is as simple as choosing the first option: Build a free-style software project.

Give it a name and you are brought to the configuration screen. There are a number of options here and I started with the basic set:

I chose Subversion for the source control management section and gave it the svn path. There is a checkout strategy as well and I chose the one to revert and update which I feel to be a bit cleaner.

I chose to poll the scm every fifteen minutes

and saved.

Running the build pulled the code out of svn and stopped there. This was because I didn’t add a step to build / install it.

Go back into configure the job and add a maven 3 build step. This automatically selected the clean install goals. Save and build now and the project was checked out and built without issues.

Success!

There are a number of other options you can play with here but this gives you a solid starting point.

Later on, I will cover the addition of various other plugins for source analysis including findbugs and pmd.