[#CLMVN-6] maven-clover-plugin uses non instrumented jars used for transitive dependencies.

Clover Maven Plugin

maven-clover-plugin uses non instrumented jars used for transitive dependencies.

Created: 04/Nov/07 08:41 PM Updated: 28/May/08 07:47 PM

Component/s:

None

Affects Version/s:

3.3

Fix Version/s:

None

Security Level:

public (Anyone can view the issue)

Time Tracking:

Not Specified

Issue Links:

Duplicate

This issue duplicates:

~~CLMVN-25~~ Clover reports don't work for cross module tests

Reference

This issue relates to:

~~CLMVN-25~~ Clover reports don't work for cross module tests

Labels:

Description

« Hide

This was originally reported as http://jira.codehaus.org/browse/MCLOVER-70

The patch available on that issue does not fix the problem (I don't know if there are other cases which it fixes)

If a project contains a war, jar1 and jar2, where jar1 has a dependency on jar2, the war will be built with a non-clovered version of jar2.

All

Comments

Work Log

Change History

FishEye

Crucible

Builds

Sort Order:

[ Permlink | « Hide ]

Llewellyn Botelho added a comment - 30/Jan/08 03:41 PM

What's the status on a fix for this issue?

[ Permlink | « Hide ]

Jerome Lacoste added a comment - 22/May/08 10:14 PM

We've reported the same problem to the maven mailing list. Cf http://jira.codehaus.org/browse/MCLOVER-70 and http://www.mail-archive.com/users@maven.apache.org/msg85358.html.

Below a copy of the message. I am not sure if the problem comes from clover or maven.

[clover:instrument forked lifecyle] modified project artifacts list do not get propagated to the WAR/EAR mojos. Is this expected ?

Jerome Lacoste
Wed, 21 May 2008 11:10:25 -0700

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

[ Show » ]

Jerome Lacoste added a comment - 22/May/08 10:14 PM We've reported the same problem to the maven mailing list. Cf http://jira.codehaus.org/browse/MCLOVER-70 and http://www.mail-archive.com/users@maven.apache.org/msg85358.html. Below a copy of the message. I am not sure if the problem comes from clover or maven. [clover:instrument forked lifecyle] modified project artifacts list do not get propagated to the WAR/EAR mojos. Is this expected ? Jerome Lacoste Wed, 21 May 2008 11:10:25 -0700 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

[ Permlink | « Hide ]

Jerome Lacoste added a comment - 22/May/08 10:19 PM

~~CLMVN-25~~ and CLMVN-6 have the same root cause. CLMWN-25 seems to have some interesting findings.

http://developer.atlassian.com/jira/browse/CLMVN-25?focusedCommentId=16756#action_16756

[ Permlink | « Hide ]

Jerome Lacoste added a comment - 25/May/08 02:58 PM

I managed to hack maven to work, but this is in an unsupported way. It required to modify the project interface and inject code from clover plugin.

See http://www.mail-archive.com/dev@maven.apache.org/msg74636.html for details. I will see if I can get a proper solution in maven, but I doubt that this will be done in the 2.0.x timeframe.

[ Permlink | « Hide ]

Jerome Lacoste added a comment - 25/May/08 11:57 PM

Here's the issue I created for maven: http://jira.codehaus.org/browse/MNG-3595

This patch is definitively not going to be accepted as is. Not sure if this is going to get fixed in a 2.0.x time frame.