ericlefevre

Fact to know: though it does not say so in the documentation, Sonar requires a fairly recent version of Maven. Version 2.0.4 failed, but 2.0.8 worked.

(more…)

The Maven Surefire page explains that -DskipTests and -Dmaven.test.skip=true can both be used to avoid running tests. If you use an old-ish version of Surefire (pre-2.4) or even if you use the latest version (2.4.2 as of February 21th, 2008), there are a couple of things you need to know.

(more…)

On the projects I work on, I always try to introduce Maven. Unfortunately, it is often impossible to get approval for a separate machine to be used as a repository. For open source packages, that is not really a problem as they are available on the usual public repositories. But some are not, so I often end up using my workstation as the server. This is not very practical, as I often shut it down when I leave for a WE or for holidays.

Another option is to use a sub-directory of your maven project to be used as a crude repository for those packages. (more…)

The crazy (8 releases in the past 30 days!) Hudson dev team has just introduced a new feature. They call it a ‘matrix project’. The idea is that a configuration would often be common to many builds. Say, one for each operating systems, times each supported JDK, times each supported database environments, etc. You could end up with dozens copies of the same Hudson configuration.

To work around this, it is now possible to specify each JDK we are targeting, plus environments variables. All combinations of parameters are then tested.

(more…)

A week ago, Maven started shouting “The plugin ‘org.apache.maven.plugins:maven-war-plugin’ does not exist or no valid version could be found”. What the…?! how can “maven-war-plugin” not exist?? Besides, it is in my repository!

As it turns out, it is a reasonably common issue. I managed to find some help on codehaus’ site, and it did help. But not every time.

Eventually, the best solution seems to simply delete the local repository and let Maven repopulate it.

From what I understand, it sometimes happens that some files (maybe the maven-metadata-central.xml ones?) get corrupted. Good luck when that happens on a enterprise-wide repository…

In version 1.2.5 of XFire, a module called xfire-spring is necessary to run it together with , well, Spring. The issue is that the POM file for it is designed to run with Spring 1.2.x.

(more…)

Surefire 2.3 for Maven has been released March 1st.
No big announcements, just a post on the maven mailing list. Still, it is a big deal for me, as I can at last run my JUnit 4 tests with Maven.
(more…)

p6spy is a JDBC proxy that will log the SQL statements passed to a database. It is a relatively old project (last release is from 2003 but I only heard about it today, as I was looking for a way to trace SQL queries sent by dbUnit to my Oracle database.
The bad news, of course, is that usage of p6spy along with dbUnit and Maven is not documented. Since it took me a while to figure it out, I thought I’d share it here.
(more…)

This is something that is not well documented on the web, though it is quite clearly in the default settings.xml file provided with the default Maven installation.

The default repository used by Maven 2 to store the various artifacts is <user_home>/.m2/repository. Under Windows, that translates to C:\Documents and Settings\<user>\.m2\repository.
On my client site, the size of the user home directory is severely restricted, presumably because it is being backed up. So, how do you change this value? Easy, once you know.

You need to have a settings.xml file, either in the <user_home>/.m2 directory, or in the <maven installation>/conf directory (make sure you keep a copy of the existing one). Add a new <localrepository> tag. On my machine, it looks like that:

<settings>  …

<localrepository>D:/mavenrepository</localrepository> <!– any type of slashes works –>

…

</settings>

That’s it!

After many spurious error messages, I finally managed to make it work. Be warned that the information on the official Cobertura Maven plugin page, the informations are not exactly correct. Below, you’ll find in bold the fixes.

The “Basic Cobertura Configuration” seems fine, however, to configure the instrumentation, you need to add the following to your config file:

<project>
  ...
  <build>
    ...
    <plugins>
      ...
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>cobertura-maven-plugin</artifactId>
        <version>2.1</version> <!– apparently, this is not necessary in the reporting part –>
        <configuration>
          <instrumentation>
            <!– <ignore>com.example.boringcode.*</ignore> –> <!– not sure how to make this work, or even if it is necessary at all –>
	    <excludes> <!– the usual ant exclude pattern was missing –>
              <exclude>com/example/dullcode/**/*.class</exclude>
              <exclude>com/example/**/*Test.class</exclude>
            </excludes>
          </instrumentation>
        </configuration>
        <executions>
          <execution>
            <goals>
              <goal>clean</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>