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