Clovered EAR / WAR artifacts lacks clovered versions of transitive dependencies. Cf: http://jira.codehaus.org/browse/MCLOVER-70. This issue still exists in the maven clover plugin 3.7 from atlassian. We've tested maven 2.0.6 and 2.0.9.
The issue is caused apparently as the clover plugins tries to modify the project artifacts list in a forked lifecycle, but the change is not propagated to the mojos executed later on. My understanding is that the way clover tries to achieve this is not possible, as the forked lifecycle ends before the war/ear mojos are executed. Can someone confirm this reasoning, and maybe provide an alternative solution to this problem ? Details: ******* The clover instrument mojo forks its own lifecycle. This lifecyle then triggers the clover instrumentInternal after the validate phase. In this forked lifecycle, the instrumentInternal mojo is bound to the install phase. In http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentMojo.java * @goal instrument * @execute phase="install" lifecycle="clover" Then http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/resources/META-INF/maven/lifecycle.xml <lifecycle> <id>clover</id> <phases> <phase> <id>validate</id> <executions><execution><goals><goal>instrumentInternal</goal></goals></execution></executions> So when we run clover:instrument as part of a WAR project we see the following things happening. [INFO] [clover:instrument] [...] [INFO] [clover:instrumentInternal] [...] [INFO] [resources:resources] [...] .... [INFO] [war:war] As part of clover:instrumentInternal, clover tries to override the project artifacts and dependency artifacts. This is done here: http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentInternalMojo.java * @goal instrumentInternal * @phase validate * @requiresDependencyResolution test private void swizzleCloverDependencies() { getProject().setDependencyArtifacts( swizzleCloverDependencies( getProject().getDependencyArtifacts() ) ); getProject().setArtifacts( swizzleCloverDependencies( getProject().getArtifacts() ) ); } According to the debug logs, the swizzleCloverDependencies does the thing properly: [INFO] [clover:instrumentInternal] [...] DEBUG] [Clover] source root [C:\b2bdev\projects\helloWorld\webapp\src\test\java] [DEBUG] [Clover] List of dependency artifacts after changes: [DEBUG] [Clover] Artifact [junit:junit:jar:3.8.1], scope = [test] [DEBUG] [Clover] Artifact [com.cenqua.clover:clover:jar:2.1.0], scope = [compile] [DEBUG] [Clover] Artifact [com.test.helloworld:app:jar:clover:1.0], scope = [compile] [DEBUG] [Clover] List of artifacts after changes: [DEBUG] [Clover] Artifact [junit:junit:jar:3.8.1], scope = [test] [DEBUG] [Clover] Artifact [com.test.helloworld:app1:jar:clover:1.0], scope = [compile] [DEBUG] [Clover] Artifact [com.test.helloworld:app:jar:clover:1.0], scope = [compile] [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-resources-plugin:2.2:resources' --> The problem is when the war mojo is invoked later on, the list of artifacts is still the old one. I.e. we miss some clovered artifacts. Did the forked life cycle stop after the execution of the instrumentInternal mojo and did the changes setArtifacts() get lost ? Or should I expect maven to appropriately pass the appropriate artifacts to the war mojo, as invoked as part of this special lifecyle ? Cheers, Jerome --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
