Indeed, generating the whole site at each build is clearly not an option. But the problem is that mvn surefire-report:report-only
doesn't create the the css/*.css files, hence the ugly result. This is logged in SUREFIRE-616 (doesn't mean something will happen though). Personally, I don't use HTML reports that much so I can live with that but that's not a good answer so here is a workaround based on the ant task (*sigh*):
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>test-reports</id>
<phase>test</phase>
<configuration>
<tasks>
<junitreport todir="target/surefire-reports">
<fileset dir="target/surefire-reports">
<include name="**/*.xml"/>
</fileset>
<report format="noframes" todir="target/surefire-reports"/>
</junitreport>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>ant</groupId>
<artifactId>ant-junit</artifactId>
<version>1.6.2</version>
</dependency>
</dependencies>
</plugin>
Update: My initial idea was to run the Maven AntRun plugin "on demand" to generate the reports... but that's not what I posted, I bound it to the test
phase... But I didn't think about the case of failed tests (that would stop the build and prevent the execution of the AntRun plugin). So, either:
Don't bind the AntRun plugin to the test
phase, move the configuration outside the execution
and call mvn antrun:run
on the command line to generate the reports when wanted.
or use the testFailureIgnore
option of the test mojo and set it to true in the surefire plugin configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<testFailureIgnore>true</testFailureIgnore>
</configuration>
</plugin>
or set this expression from the command line using the -D parameter:
$ mvn test -Dmaven.test.failure.ignore=true
I think that Option #1 is the best option, you don't necessarily want to generate the reports (especially when the test passes) and generate them systematically may slow down the build on the long term. I'd generate them "on demand".