simply discuss the ramifications of defaulting the core plugin versions in the super pom in 2.0 only.
+1, might also spare users from learning yet another concept like "plugin-packs". If the super POM locks down all plugins that would be injected by one of the various lifecycle mappings and the user himself locks down any additional plugins he explicitly configured in the POM, why bother with something like "plugin-packs". Besides, I do not see much value in an attempt to pack/group plugins given the fact that each plugin has its own release cycle, i.e. there are more version combinations of plugins from which I want to choose than you want to provide plugin packs for. Last but least and please don't take this as an offense but if you are honest you have to confess that implementation of inheritance is buggy/complex enough. As a user interested in a stable build tool, I really dislike the idea of another concept that interferes with plugin resolution.
Those who have followed best practice and locked their versions down will not be affected by this at all.
The reality looks different: http://jira.codehaus.org/browse/MNG-3394 As a prerequisite for the proposed additions to the super POM, this issue should be fixed. Regards, Benjamin Bentmann --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
