[ACCEPTED]-Maven2 - problem with pluginManagement and parent-child relationship-maven-2
Adding the plugin configuration to pluginManagement 18 means that this configuration will be used 17 if the plugin is declared, but you still 16 need to declare the plugin in the build 15 section of any POM that wants to use it.
The 14 key part that explains this from the section 13 you quoted is:
However, this only configures 12 plugins that are actually referenced within 11 the plugins element in the children
So if 10 you do this in the child pom the configuration 9 from the parent will be applied:
<build> <plugins> <plugin> <artifactId>maven-dependency-plugin</artifactId> </plugin> </plugins> </build>
Update: To 8 answer the actual question, the content 7 from the pluginManagement section is always 6 merged with any plugin declaration. To avoid 5 the parent doing this, you can define the 4 pluginManagement section within a profile, and 3 activate that profile on child projects 2 but not the parent. The child projects would 1 then have to declare that profile.
<profiles> <profile> <id>for-children</id> <build> <pluginManagement> <plugins> <plugin> <artifactId>maven-dependency-plugin</artifactId> <version>2.0</version> <executions> <!--Some stuff for the children--> </executions> </plugin> </plugins> </pluginManagement> </build> </profile> </profiles> <build> <plugins> <plugin> <artifactId>maven-dependency-plugin</artifactId> <version>2.0</version> <inherited>false</inherited> <!-- this perticular config is NOT for kids... for parent only --> <!--some stuff for adults only--> </executions> </plugin> </plugins> </build>
I always used to think that a child POM 22 can inherit a plugin definition from its 21 parent's pluginManagement section and specify 20 only the executions it wants to run from that 19 plugin by referencing them by ID and binding 18 the execution to a phase. As long as the parent definition 17 is in pluginManagement (and not directly 16 in plugins) and is not bound to a phase, only 15 the specific execution (with ID) will be 14 run in that phase.
From reading the above, and 13 from my own current problem, it looks like 12 that's not true: it looks like a child POM 11 will inherit the entire configuration of 10 the plugin, including all executions. In 9 terms of executions, the only thing the 8 child can do is to override specific values 7 - it cannot pick which executions to run, and 6 which not to.
Is this a bug? What's the use 5 of being able to bind each execution to 4 a phase (or not), if all executions will 3 be run? I've only seen it with maven-dependency-plugin:unpack 2 (bound to package phase), but with other plugins 1 I might just have been lucky...
In parent pom you should configure executions 14 with
<goals> declared but don't declare
<phase>. Then 13 in the child pom you'll declare:
<plugin> <artifactId>some-plugin</artifactId> <executions> <execution> <id>execution-id</id> <phase>partcular-phase</phase> </execution> </executions> </plugin>
The plugin 12 won't be executed until you define a phase 11 in the child pom. Thus you'll need to explicitly 10 bind executions to phases in every child 9 pom (or in the middle of hierarchy), but 8 you won't need to copy-paste configuration 7 of these executions.
Note, that lots of plugins 6 have Default Phase, e.g. Enforcer Plugin 5 is bound to
validate by default. Even if you don't 4 bind plugin to a phase explicitly, it will 3 be bound anyway and thus the plugin will 2 be executed. To overcome this, use non-existing 1 phase in your parent:
<execution> <id>execution-id</id> <goals><goal>some-goal</goal></goals> <phase>none</phase> </execution>
You must assign an ID to the execution so 2 maven knows which ones overwrite each other 1 and which are independent.
More Related questions