As of maven 2.0.9 they introduced deterministic ordering of dependencies on the classpath, however when the clover plugin rebuilds the test classpath that ordering is changed. And furthermore, since you change the order of the direct dependencies, when the transitive dependencies are resolved again some of the versions may change. Most likely, rather than creating a regular HashSet when building the dependency list, you should be using a LinkedHashSet to maintain the ordering from maven.

Attached is a simple project and pom that demostrates the issue. If you run mvn clean site -X the classpath for clover generation is reordered and ends up with commons-collections-2.1.1 as opposed to 3.2 from the regular surefire testing. Obviously, this leaves open the possibility that test may fail during clover generation when they succeed during the initial maven testing. I have a project that I stripped down for the example where I believe that is what is happening.