You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Nick Pellow (JIRA)" <ji...@codehaus.org> on 2009/06/03 04:04:42 UTC

[jira] Commented: (MNG-3595) Changes made to project resolved artifacts are overriden when a plugin uses @requiresDependencyResolution

    [ http://jira.codehaus.org/browse/MNG-3595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=179092#action_179092 ] 

Nick Pellow commented on MNG-3595:
----------------------------------

Bump - has there been any decision as to the best way to move forward? This issue is rather limiting to Clover and any other plugins which create classified artifacts.
What about applying Jerome's patch to Maven, and seeing what breaks? I am guessing not a lot would, since it is an extra plugin point, and is backward compatible with previous functionality.

> 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
>             Fix For: 3.x
>
>         Attachments: MNG-3595-test-project.tar.bz2, MNG-3595.diff, MNG-3595.diff
>
>
> 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/dev@maven.apache.org/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