We spent an hour or two yesterday trying to get the Maven assembly plugin configured and working as documented. A number of experiments later we found the problem: we had placed our <plugin> element along with all of the other <plugin> elements defined in the <build> section of pom.xml, following the existing pattern, not noticing that it was nested within the <pluginManagement> element.
<project> <build> <pluginManagement> <plugins> <plugin>... oops, here ...</plugin> </plugins> </pluginManagement> <plugins> <plugin>... not here! ...</plugin> </plugins> </build> </project>
So what’s the difference? According to the Maven POM reference, the <pluginManagement> section contains:
Default plugin information to be made available for reference by projects derived from this one. This plugin configuration will not be resolved or bound to the lifecycle unless referenced. Any local configuration for a given plugin will override the plugin’s entire definition here.
We were trying to bind our assembly to the default lifecycle, and I see a reference to the keyword lifecyclein there, although I’m not really sure I understand the comment.
Moving our <plugin> element to the top level of <build><plugins> did the trick for us. But a quick search shows that we use the <pluginManagement> element in many of our POM files, either wittingly or unwittingly.
The moral: if your plugin configuration doesn’t seem to be working as documented, check to see where it is in the POM.