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]
