http://jira.codehaus.org/browse/MVERSIONS-6 and http://jira.codehaus.org/browse/MVERSIONS-7 should give what you want when I get around to writing them...
the blocker for me is having stable integration tests, which depends on finishing mock-repository-maven-plugin... and swamped in work and I have a 10 month old son taking all my spare time up ;-) -Stephen On 12 October 2010 17:55, Patrick Aikens <[email protected]> wrote: > Thanks for that - it's at least useful in getting a report of which > version to put in our pluginManagement section in the parent. The pom > updating doesn't seem to include a goal that will update plugin > versions, but given a list we can do that by hand. > > On Tue, Oct 12, 2010 at 12:41 PM, kristian <[email protected]> wrote: >> try >> mvn versions:display-plugin-updates >> which should give you an overview. there is more to the plugin and it >> does insert the versions where needed with one of its goals. >> >> regards Kristian >> >> On Tue, Oct 12, 2010 at 10:00 PM, Patrick Aikens <[email protected]> wrote: >>> I do agree that from a repeatability standpoint, specifying versions >>> for ALL plugins is desirable - but since Maven provides a super-pom >>> that everything inherits from we get certain plugins automatically. >>> Aside from looking at that pom and basically copying the build.plugins >>> section there's no simple way for an end-user to know that you should >>> specify version 2.3.2 of the compiler plugin (and repeat that for >>> every other default plugin), or even what the list of default plugins >>> contains. Granted, there could be a plugin to add that info to your >>> pom... maybe add it to the archetypes and also have a stand-alone mojo >>> to add default plugin info to the current project's pom - run that on >>> your parent pom and modify as necessary. >>> >>> My question of which should be the case still stands, though - >>> repeatable builds and best practices aside, the way it works today >>> Maven will continue to update and you'll silently be using new >>> versions of those plugins anyway without warnings when you upgrade. >>> The only reason I'm seeing those warnings is because I attempt to >>> merge in new configuration to those plugins. There's inconsistent >>> behavior here - either we need to lock down all the plugin versions in >>> our own poms (even for default plugins where we use default >>> configurations) for repeatability purposes, or we can rely on >>> inheriting merged info for those plugins into our overridden >>> configurations. I'm not sure the current state is desirable. Maybe >>> this should go to the dev list since it seems to be more of an >>> implementation question? >>> >>> On Tue, Oct 12, 2010 at 11:47 AM, Paul Benedict <[email protected]> >>> wrote: >>>> Yes, Maven provides default versions, but those are likely to change >>>> as Maven does future patch releases. To give you a predictable build, >>>> lock down your plugins so you control what versions are selected. >>>> >>>> Paul >>>> >>>> On Tue, Oct 12, 2010 at 10:27 AM, Patrick Aikens <[email protected]> wrote: >>>>> I've got several projects that provide additional configuration of >>>>> standard Maven plugins (like the compiler plugin or the jar plugin), >>>>> most commonly changing the source and target values for the compiler >>>>> plugin. Unfortunately, I get the following warnings: >>>>> >>>>> [WARNING] 'build.plugins.plugin.version' for >>>>> org.apache.maven.plugins:maven-compiler-plugin is missing. >>>>> [WARNING] 'build.plugins.plugin.version' for >>>>> org.apache.maven.plugins:maven-surefire-plugin is missing. [WARNING] >>>>> 'build.plugins.plugin.version' for >>>>> org.apache.maven.plugins:maven-jar-plugin is missing. >>>>> >>>>> I know (and approve of) Maven 3.0 requiring versions on plugins, but >>>>> shouldn't these particular plugins have versions specified in the >>>>> super-pom that get merged into the references in my projects? Is it >>>>> expected behavior that to add configuration to these plugins that I go >>>>> find out which version of the plugin is in the super-pom and add it >>>>> again? I can get rid of these warnings by simply putting the >>>>> appropriate plugin version information in a common parent pom's >>>>> pluginManagement section, but I'm not sure that I should need to. >>>>> >>>>> It just seems odd that I need to repeat the version info if I add some >>>>> configuration to the plugin in a project, but another project that >>>>> just uses the plugin as-is through inheritance from the super-pom >>>>> works without warnings... it should have warnings in both or neither. >>>>> >>>>> -- >>>>> SELECT * FROM users WHERE clue > 0 >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> >>> >>> -- >>> SELECT * FROM users WHERE clue > 0 >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > > -- > SELECT * FROM users WHERE clue > 0 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
