In 2.x the plugins you get from the lifecycle depend on which phase was executed, and it frankly drove me crazy trying to write the enforcer plugin rules. I think there are several things a plugin should be able to get: 1) the original model as parsed from disk with no interpolation or inheritence 2) the effective original model 3) the model as executed - this would be where the lifecycle plugins get included.
On Sat, Jan 9, 2010 at 12:57 PM, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: > 2010/1/9 Peter Lynch <pe...@peterlynch.ca>: >> On Sat, Jan 9, 2010 at 7:36 AM, Stephen Connolly < >> stephen.alan.conno...@gmail.com> wrote: >> >>> 2010/1/9 Benjamin Bentmann <benjamin.bentm...@udo.edu>: >>> > Hi, >>> > >>> > in response to http://jira.codehaus.org/browse/MNG-4523, I would like to >>> > double-check that the behavior observed in Maven 2 is by >>> design/intention >>> > and needs to be reproduced by Maven 3. It looks odd to me that the >>> effective >>> > POM is a function of the plugin being invoked on CLI. >>> >>> I agree that it looks odd. >>> >>> IMHO, the effective pom should be invariant. >>> >>> >> It is far from invariant. I noticed in the debugger that the project model >> contained 4 plugins ( clean,site, install, deploy if i recall), none being >> the one explicitly called in Maven 3. In Maven 2, the only plugin in the >> model was the one being called. After that I thought I'd better share my >> findings... >> >> > > I would expect to see the plugins from the default lifecycle bindings, > which for a pom project should be clean, site, install and deploy > IIRC. I would not expect to see the plugin executed on the command > line. > > I would expect to see the plugin executed from the command line to > have been configured according to the def from pluginMgmt, but I would > not expect to see it in the project model (i.e. in > /project/build/plugins/plugin) unless it is explicitly listed in the > pom. > > IMHO the Maven 2 behaviour is the bug and Maven 3 fixes it. > > -Stephen > > P.S> we still await Jason to weigh in on this one though! ;-) > >>> > >>> > >>> > Benjamin >>> > >>> > --------------------------------------------------------------------- >>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> > For additional commands, e-mail: dev-h...@maven.apache.org >>> > >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org