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]
