Tag Archives: maven

I have finally install Java 7 on my laptop. The Java install runs just fine. Getting maven to find it however was a little tricky.

To make Maven find Java 7 the JAVA_HOME variable is required again. This hasn't been used for a while since Maven have been able to find Java anyway. But with the switch to 7 Maven still uses Java 6 by default.

I always use .bash_profile to change my environment variables since I tend not to need them else were. It is located in the users home directory (I.E. ~/.bash_profile).

The path to the new Java install is '/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/'. So the complete setting should look like this:


When this has been configured Maven will use Java 7.

Have you ever got a ClassNotFoundException when running tests and yet the dependency that contains the jar is clearly in your pom file? This is most commonly due to collations in transitive dependencies. If Maven cannot decide which version of a dependency to use it will not import it. It will expect you to sort the problem out first.

Handling transitive dependencies should always be done pro-actively. And there is some really good tooling for it. Being a IntelliJ/IDEA developer my self it saddens me to say that in this instance my favourite IDE is outdone by NetBeans. NetBeans uses Maven pom files as it's project descriptors which makes it very easy to open the project.

When the project is opened in NetBeans you will find the pom.xml file located under project files in the project navigator. Once opened you will find an item named "Show Dependency Graph" in the context menu. This will render a graphical representation of all the projects transitive dependencies.

If any of the dependencies has a red top left corner there is a version conflict. Resolving it is done quickest by opening the context menu for the dependency and selecting "Fix Version Conflict". Unless you have a specific preference that differs from the default suggestion in the dialogue it is usually fine to got with the default solution.

If any of the dependencies has a yellow top left corner there are more then one version of the dependency requested. Maven will always choose the latest version in the list. This can, and should, however be overridden using the exclusions tag. I tend to take control over all such dependencies buy making sure I clearly choose which one should be included. You have to do this manually by excluding the dependency from each of the dependencies where the version you do not want is included and then ensure that the dependency requiring the correct version is the only one still including it. Sometimes it's better to exclude it as a transitive dependency altogether and add it as a direct dependency.

Whenever a new dependency is added to the project I make sure to perform the same procedure to ensure that I have full control of the dependencies in my project.

I would be very pleased to find such a great tool in IDEA as well, then I wouldn't have to run two IDEs at the same time, they do require a lot of resources.

1 Comment

Ever wanted Maven to print the test output to the terminal to save yourself from digging around in the surefire report directory to find out what happened with the failing tests? I have many times but have never invested the time to find out how until now.

It's pretty straightforward. Set the useFile flag to false in the surefire plug-in. To also skip the xml report output you can set the disableXmlReport to true. Then there will be no reports created when running the tests. Use the profile below to enable this in your pom.

Please note that for some odd reason my syntax highlighter lower case all tags. It should be groupId, artifactId, disableXmlReport and useFile in camel case.

To activate this profile you need to add -Pdev. You could have it active by default but then your CI server will not have any test reports. And whilst no reports are fine on the developer machine it's not very practical on the CI server.

I wanted to automate start of my SLAMD server for faster development time when porting on façades to the underlying SLAMD system. SLAMD ships with a Tomcat 6 server so the obvious way to do this is to use the Cargo plugin for Maven.

Below is the configuration that automatically pushes my classes to the server and then starts the server. They are configured in a profile since I don't want this to happen on all builds.

This will first remove any classes from the SLMD web app in the Tomcat container that lives under the package com. It will then copy all built classes to the SLAMD server. It will then launch Tomcat and wait for a ctrl-c to break execution. This will all happen in the package build phase.

This makes it fairly quick to deploy and test changes made to extensions of the SLAMD server.


After having automated our android project and getting everything to work, up and running on hudson and so on, we realised that the Android manifest xml file did not get automatically updated with the correct version numbers.

My initial idea was to use normal Maven properties, we do that in other parts of the project, to populate the values. However this does not work since the versionCode attribute must have an integer value for Eclipse to work. This ment that I would need to change the actual values in the manifest.

I had read a couple of blog posts about a Maven plugin called GMaven that have intrigued me. The plugin makes it possible to embed a Groovy script into a pom file and execute it during the build. Since Groovy makes changing XML easy this was the perfect fit.

Below is a script, embedded into the pom directives needed, that will automate setting version in the AndroidManifest.xml. It is triggered using the profile manifest-version-update. When triggered it will set the versionName attribute to the maven project version. It will also increment the versionCode attribute with 1 (versionCode++). The script should be placed in the Android application pom (I.E if you use a hierarchical structure this does not go in the parent pom).

I have yet to figure out how I can automatically trigger this when running the Maven release plugins prepare step. It would be perfect if it can be triggered once for the release pom and once for the snapshot pom during the release:prepare phase so that both the release tag and the trunk of the project has the correct version numbers. But that will have to wait a while.