1

Earlier this week I had a great deal of difficulty reverting the project properties that Clover changes when it runs (so that it wouldn't interfere with subsequent plugins):

How to revert Maven project.build variables after Clover plugin finishes?

I solved this issue by saving these properties when Maven starts up and using the saved variables in my plugins instead of the ones which Clover alters.

Now that I'm able to host the non-instrumented WAR file in the pre-integration-test phase my tests are able to run successfully and pass (previously, I was unable to run the app from the instrumented WAR file since Clover was not on the release class path).

Unfortunately, I'm finding that the forked Clover life cycle continues beyond the test phase. After my tests pass and the embedded Tomcat instance shuts down the original lifecycle runs the Tomcat7 plugin again, starts the server, and re-runs the test.

I can live with it running my unit tests twice (this can catch edge case bugs which only appear with or without Clover instrumentation), but running my integration tests twice is entirely unnecessary. These tests don't touch the production code (they're using Selenium to automate UI testing against it in the browser). As mentioned, the instrumented WAR file was not working anyway, so it's no longer even there when the integration tests are run. There is absolutely no reason that these tests need to be run again.

How can I tell Clover to terminate the forked lifecycle after the test phase completes so that the integration tests will only run once? I'm currently only able to enable it for the entire lifecycle or not at all.

Update: I've found that even if I disable the Clover plugin by passing in -Dmaven.clover.skip=true that it will still fork the lifecycle. The only way I've found to prevent this is to comment out the Clover plugin entirely so that it does not have a chance to fork the lifecycle before skipping instrumentation.

Community
  • 1
  • 1
Alex Jansen
  • 1,455
  • 5
  • 18
  • 34

1 Answers1

0

Clover has three goals which can be used for code instrumentation:

The clover2:instrument forks a parallel build life cycle till the 'install' phase - this a reason why you see your build and tests running twice - once for a standard build and once for a build with Clover. The clover2:instrument produces also two sets of artifacts - normal ones (e.g. myapp-1.0.jar) and "cloverized" ones (e.g. myapp-1.0-clover.jar).

There is also a similar goal named clover2:instrument-test - it forks a build too, but till the 'test' phase. It may be useful in case you don't want to run integration tests or you want to avoid installing artifacts in a local Maven cache.

If you don't like this behaviour, you can use the clover2:setup goal instead. It will perform source code instrumentation in Maven's default build life cycle. Which means that both build and tests are performed only once. The only thing you have to keep in mind using the clover2:setup is that generated artifacts (JARs, WARs) will contain instrumented classes and thus the most probably you shall not call 'mvn install' or 'mvn deploy' together with 'clover2:setup' - in order to avoid pushing "cloverized" JARs into your repositories :-)

In case you're running your tests on CI, I suggest configuring a separate build plan with 'clover2:setup'. Feel free to contact me at support.atlassian.com if you have any questions.

Marek
  • 748
  • 6
  • 13
  • We'd still like to fork the life cycle and run the unit tests twice (as per http://stackoverflow.com/questions/15795840/maven-runs-unit-tests-twice-with-clover-plugin). However, using clover2:instrument-test (as you've suggested at http://stackoverflow.com/questions/25984565/how-to-revert-maven-project-build-variables-after-clover-plugin-finishes) actually solves my issue and keeps the integration tests running only once (as desired). Would you mind updated this answer to mention that as well so I can accept it? – Alex Jansen Oct 08 '14 at 19:41