You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org> on 2010/03/18 11:33:23 UTC

[jira] Closed: (MNG-4595) Unwanted parent plugin execution

     [ http://jira.codehaus.org/browse/MNG-4595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benjamin Bentmann closed MNG-4595.
----------------------------------

    Resolution: Not A Bug
      Assignee: Benjamin Bentmann

This works as designed. When a child project references a plugin from a parent's plugin management section, all inherited plugin executions are applied to the child, not just those that the child customizes.

> Unwanted parent plugin execution
> --------------------------------
>
>                 Key: MNG-4595
>                 URL: http://jira.codehaus.org/browse/MNG-4595
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Inheritance and Interpolation
>    Affects Versions: 2.2.1
>         Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_18
> Java home: C:\Program Files\Java\jdk1.6.0_18\jre
> Default locale: en_GB, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>            Reporter: Cornel Masson
>            Assignee: Benjamin Bentmann
>         Attachments: MavenTest.zip
>
>
> Searched far and wide but haven't found an answer, so I'm logging this bug.
> See attached project zip which demonstrates the problem:
> * Project 'util' has 2 assemblies as artifacts:
> ** util-config.zip
> ** util-unwanted-stuff.zip
> * Project 'test-project' depends on 'util's util-config.zip and uses the maven-dependency-plugin to unpack it from the repository
> * 'test-project' has project 'root' as parent
> * 'root' defines the actual maven-dependency-plugin:unpack executions: one for unpacking util-config.zip (id = {{unpack-util-config}}) and another for unpacking util-unwanted-stuff.zip (id = {{unpack-unwanted-stuff}}). This is in pluginManagement - and no phase binding is specified in root - so it's inherited by 'test-project', but not automatically executed.
> * 'test-project' references the inherited maven-dependency-plugin execution with id {{unpack-util-config}}, and binds it to phase _package_, i.e. only this one assembly should be unpacked:
> {code:xml}
> <plugins>
> 	<plugin>
> 		<artifactId>maven-dependency-plugin</artifactId>
> 		<executions>
> 			<execution>
> 				<id>unpack-util-config</id>
> 				<phase>package</phase>
> 			</execution>
> 		</executions>
> 	</plugin>
> </plugins>
> {code}
> However, when you run {{mvn package}} on test-project, both assemblies are unpacked. Maven has run both the {{unpack-util-config}} *and* {{unpack-unwanted-stuff}} executions of the plugin, as defined in 'root'. It should only have run {{unpack-util-config}}, since that is the only one referenced by 'test-project'.
> A workaround is to insert a phase binding with a *non-existing phase* for {{unpack-unwanted-stuff}} in 'root', e.g.:
> {code:xml}
> <execution>
> 	<id>unpack-unwanted-stuff</id>
> 	<phase>dont-run-this-by-default-stupid-maven</phase>
> 	<goals>
> 		<goal>unpack</goal>
> 	</goals>
> {code}
> If you run {{mvn package}} on test-project again, it won't run the {{unpack-unwanted-stuff}} with the other one. The fact that this workaround exists makes me wonder if it's related to the "Default Mojo Executions" issue as discussed in http://maven.apache.org/guides/mini/guide-default-execution-ids.html. However, this article claims these issues are fixed as from Maven 2.2.0 onwards (my tests were on 2.2.1).
> I've only experienced this problem with the maven-dependency-plugin. I ran a similar test with _maven-resources-plugin_, but it seems to work correctly, so it might only be related to maven-dependency-plugin. Not 100% sure of this.

-- 
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