As the father of an 11 month old daughter, I understand. :) On Oct 13, 2010, at 4:58 AM, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote:
> 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 <paik...@gmail.com> 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 <m.krist...@web.de> 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 <paik...@gmail.com> 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 <pbened...@apache.org> >>>> 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 <paik...@gmail.com> >>>>> 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: users-unsubscr...@maven.apache.org >>>>>> For additional commands, e-mail: users-h...@maven.apache.org >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: users-h...@maven.apache.org >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> SELECT * FROM users WHERE clue > 0 >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: users-h...@maven.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> >> >> >> >> -- >> SELECT * FROM users WHERE clue > 0 >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
