You don't bind a plugin to a phase but rather a plugin's goal. So it is possible to do what you want by having just one plugin declaration but two executions specified (for plugin A); one execution for goal A1 bound to the generate-resources phase and one execution for goal A2 bound to the process-resources phase. There's an example in [1].
The warning is a warning right now, it will still work. However, this support can be removed in future versions of Maven. [1] http://maven.apache.org/guides/mini/guide-configuring-plugins.html#Using_the_executions_Tag /Anders On Tue, Dec 23, 2014 at 10:11 PM, David Hoffer <dhoff...@gmail.com> wrote: > I have some questions regarding the duplicate plugin declaration warning, > e.g. > > [artifact:mvn] [WARNING] 'build.plugins.plugin.(groupId:artifactId)' must > be unique but found duplicate declaration of plugin > org.apache.maven.plugins:maven-xxx-plugin > > First is this a benign warning that can be ignored or is it really > something that is not supported (multiple declarations of the same plugin) > and that I really need to remove? > > If it's the later case this really limits the flexibility of plugins, let > me explain with an example. > > If my current build does the following in order: > > Plugin A - Phase: generate-resources > Plugin B - Phase: process-resources > Plugin A - Phase: process-resources > > By defining plugin A twice I'm able to use the most appropriate phase for > each instance of the plugin (btw, each instance has several executions). > The key to the above is that plugin B has be be done between each of the > two instances of plugin A. > > If I had to only have one plugin A I'd have to set the phase in the later > case to something later than process-resources (or I'd have to adjust the > first one to something earlier). Not only does it make it harder to follow > the flow (later in the pom is more clear) but it sometimes forces the use > of poor phases as I have many other plugins in this pom after/before these > that are tied to phases as well so it limits what can be chosen here to > satisfy a no duplicate plugin rule. > > What's really the rule here regarding duplicate plugins? > > -Dave >
