[
http://jira.codehaus.org/browse/MNG-3595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136554#action_136554
]
John Casey commented on MNG-3595:
---------------------------------
I'd prefer to see this as preventing re-resolution of project dependencies,
unless the scope changes upward (compile to test, NOT test to compile)...then,
you could impose a rule saying that any pre-existing dependency artifacts in
the project are preferred over those new ones just resolved...that way, you'd
preserve any swizzled artifacts for the duration of your forked execution.
This does get into some interesting side effects for plugins that don't use
@requiresDependencyResolution, probably, so it's probably not appropriate for
2.0.x (who knows what sort of regressions this sort of change could introduce).
I'd prefer to do a full audit of the mutability of MavenProject for 2.1 from a
plugin's point of view, to make sure that modifications like this are preserved
for successive plugin-executions.
> 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, 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/[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
