Sometimes you may find that your tests are run twice, once to make
the report for the site (thus not breaking the build if they fail) and
second time to create a jar, war or any other artifact, and probably in
this step you want the build to break if tests don’t succeed. This is
very common in a continuous integration scenario where the machine with
CruiseControl or any other CI tool deploys the site and generated
artifacts.

My suggestion is to create a goal in your maven.xml like this

    <goal name="continuousintegration">
        <attainGoal name="clean"/>
        <attainGoal name="site:deploy"/>
        <!-- avoid running tests again -->
        <j:if test="${maven.test.failure}">
          <fail message="There were test failures."/>
        </j:if>
        <j:set var="maven.test.skip" value="true"/>
        <attainGoal name="jar:deploy"/>
        <j:set var="maven.test.skip" value="false"/>
    </goal>

The trick is checking the maven.test.failure property after creating
the site, if it’s true the build has to fail and if it’s false you can
skip tests in next steps.

Lately I had the bad time to use the Perforce SCM system. I created a maven goal to sync (=cvs update) my sources from the SCM.

You need:

• jakarta oro as a dependency in your project.xml and loaded by the root classloader.

        <!--
         | Oro is needed by the Perforce tasks and needs to be loaded
         | by the root classloader
         +-->
        <dependency>
            <groupId>oro</groupId>
            <artifactId>oro</artifactId>
            <version>2.0.8</version>
            <properties>
                <classloader>root</classloader>
            </properties>
        </dependency>

• The actual goal in maven.xml

      <!-- perforce -->
      <goal name="p4sync">
          <p4sync view="//depot/whatever/..." />
      </goal>

You can check all the perforce ant tasks you can use besides p4sync.

Cobertura is a free Java tool that calculates the percentage of code
accessed by tests. It can be used to identify which parts of your
Java program are lacking test coverage. It is based on jcoverage, but more actively developed.

I will talk about the maven cobertura plugin,
after releasing the first two versions (7/11 and 7/21) you can have
cool reports about test coverage and the ability to see all the classes
that don’t meet your minimum coverage criteria, both at line and branch
level.

The first report about code coverage is pretty similar to the one provided by Clover, but the second one
makes the difference, not provided by clover and in fact neither by
cobertura ant tasks, just the maven plugin. Another interested feature
to be used for instance in conjuction with a continuos integration tool
as CruiseControl is the option to make the build fail if any of the
classes test coverage fails below a threshold you can set. AFAIK clover
only allows to fail the test if the overall code coverage doesn’t meet
the requirements, not class by class, which is very convenient.

To use it in your maven projects you can add the dependency to the plugin
        <dependency>
            <groupId>maven-plugins</groupId>
            <artifactId>maven-cobertura-plugin</artifactId>
            <version>1.1</version>
            <type>plugin</type>
        </dependency>
and the report
        <report>maven-cobertura-plugin</report>

I hope you find it useful.