On 11/01/2010, at 5:47 AM, Benjamin Bentmann wrote: > Brett Porter wrote: > >> From an execution PoV, I would still expect my pluginManagement blocks to >> apply to a plugin called on the command line that is not otherwise in the >> POM. However, if this makes things too complicated and we want to require a >> change to include the plugin in the POM as well as the management for it to >> apply - that is probably ok if it is documented. > > Please don't mix different aspects here. I have not asked how a plugin should > be configured when it gets executed. My question is about how > > MavenProject.getModel() > > should look like. This is related but nevertheless independent from plugin > configuration. >
That's why I answered addressing both aspects :) If the execution side still works that way, that's great. It may still impact how you want the API to look for consistency. Sorry, so having trouble distilling my thoughts - something tells me that getModel() might need to return the 'runtime' model for most compatibility, and a more distinct method name (say, getResolvedModel()) is needed for the one that should always look the same, but I'm not convinced as in a green field I'd prefer the 'runtime' model be the 'optional' one and as I said before, maybe not even necessary. Also coming to mind is that -D and environmental factors from profile activation probably affect the model you get back as well? What is the original use case that led to the bug? I'm wondering if it is sane and needs the runtime info, or if it actually should have just the POM as fully resolved from the repo. Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
