[
http://jira.codehaus.org/browse/MNG-3595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jerome Lacoste updated MNG-3595:
--------------------------------
Attachment: MNG-3595-test-project.tar.bz2
a simple test project that contains a log produced after patching maven and
cloved plugin with the hack .
Notice how the expected-mvn.log contains:
[INFO] Building war:
/tmp/clover-war-hello-world-trunk/webapp/target/clover/sayHello-1.0-clover.war
[DEBUG] adding directory META-INF/
[...]
[DEBUG] adding entry WEB-INF/lib/a-1.0-clover.jar
[DEBUG] adding entry WEB-INF/lib/clover-2.1.0.jar
[DEBUG] adding entry WEB-INF/lib/b-1.0-clover.jar
while maven will today include b-1.0-clover.jar and a-1.0.jar
> Changes made to project resolved artifacts are overriden when a plugin uses
> @requiresDependencyResolution
> ---------------------------------------------------------------------------------------------------------
>
> Key: MNG-3595
> URL: http://jira.codehaus.org/browse/MNG-3595
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
> Reporter: Jerome Lacoste
> Attachments: MNG-3595-test-project.tar.bz2
>
>
> clover:instrument mojo creates instrumented artifacts and attaches them with
> a 'clover' classifier.
> It forks a lifecycle [1][2] and which triggers clover:intrumentInternal which
> tries to change the project direct and transitive dependencies after
> 'swizzling' them [3] (replacing normal artifacts with their clovered ones).
> This in theory would allow to build clovered WAR and EAR, i.e. WAR/EAR
> containing all available clovered dependencies.
> Unfortunately maven handles direct and transitive dependencies differently
> [4]. While direct dependencies are somewhat preserved (the code comments
> references clover), transitive dependencies are re-resolved, and thus the
> results of the swizzling operation are lost as soon as a plugin
> requiresDependencyResolution in a further part of the lifecycle.
> I've managed to hack maven and clover:instrument to work together by allowing
> a plugin to attach some sort of "dependency resolution post processing"
> operation [5].
> In the case of clover:instrument, the swizzling is then registered in the
> maven project and re-performed each time the artifacts are re-resolved.
> I am not very fond of this solution, but it seems to work for us on the
> attached example. I will further test the patch this week on a large scale
> project.
> I would like to discuss ways to solve this interaction, whether the clover
> plugin should be implemented differently or if maven should have some sort of
> support for this use case.
> [1]
> http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentMojo.java
> [2]
> http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/resources/META-INF/maven/lifecycle.xml
> [3]
> http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentInternalMojo.java
> [4]
> http://maven.apache.org/ref/2.0.9/maven-core/xref/org/apache/maven/plugin/DefaultPluginManager.html#1406
> [5] http://www.mail-archive.com/[EMAIL PROTECTED]/msg74636.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
