From issues-return-53319-apmail-maven-issues-archive=maven.apache.org@maven.apache.org Wed Jun 03 02:05:01 2009 Return-Path: Delivered-To: apmail-maven-issues-archive@minotaur.apache.org Received: (qmail 8701 invoked from network); 3 Jun 2009 02:05:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 3 Jun 2009 02:05:01 -0000 Received: (qmail 59725 invoked by uid 500); 3 Jun 2009 02:05:13 -0000 Delivered-To: apmail-maven-issues-archive@maven.apache.org Received: (qmail 59640 invoked by uid 500); 3 Jun 2009 02:05:13 -0000 Mailing-List: contact issues-help@maven.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@maven.apache.org Delivered-To: mailing list issues@maven.apache.org Received: (qmail 59630 invoked by uid 99); 3 Jun 2009 02:05:13 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Jun 2009 02:05:13 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [63.246.2.115] (HELO codehaus01.managed.contegix.com) (63.246.2.115) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Jun 2009 02:05:02 +0000 Received: from codehaus01.managed.contegix.com (localhost.localdomain [127.0.0.1]) by codehaus01.managed.contegix.com (Postfix) with ESMTP id 160B6162006F for ; Tue, 2 Jun 2009 21:04:42 -0500 (CDT) Message-ID: <20966866.102681243994682067.JavaMail.haus-jira@codehaus01.managed.contegix.com> Date: Tue, 2 Jun 2009 21:04:42 -0500 (CDT) From: "Nick Pellow (JIRA)" To: issues@maven.apache.org Subject: [jira] Commented: (MNG-3595) Changes made to project resolved artifacts are overriden when a plugin uses @requiresDependencyResolution In-Reply-To: <19152344.1211747781816.JavaMail.haus-jira@codehaus01.managed.contegix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 4e90ceb663894a42f12c0e28abbab431 X-Virus-Checked: Checked by ClamAV on apache.org [ 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