On Sun 14 May 2017 at 08:51, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> thank you Robert: this is exactly the logic I was looking for, and > explanation > of changes over time to improve user experience through reproducibility. > > Now the question is: should we change default plugin versions in Maven > core? > Does it improve Maven or not? I think we should. If we don't update, we have a more complex ux for new users. We already say to pin versions (iirc we even log warnings) If people choose to ignore the warnings of a build being at risk of differential behaviour... they get what they configured: differential builds > > To me, changing default plugin versions lowers reproducibility. Which is why we warn users... and the warning is there *to allow us to upgrade* > And it does not help users learn that they should define their own plugin > versions instead of depending on the magic defaults that have to be > included > in Maven core to permit basic poms. This sounds like an argument that we should add a CLI flag turn downgrade the current warnings back to warnings and escalate them up to errors by default. > > Then in general, if we have found a bug in a plugin with default version > that > hits users using this default basic poms, we should update the version: > good > default behaviour requirement surpasses reproducibility over Maven version > expectation. > > But if a plugin default version upgrade is just to have newer defaults, > IMHO, > we sacrifice reproducibility and teaching to users that basic poms are > just a > quick start but should soon be extended to manage explicitely plugins > versions: is there a good reason to sacrifice this? I don't find any good > reason: the sooner user discovers that he's using old plugins, the better. > > What we should give him are easy to discover and learn recipes to manage > his > plugin versions: for example through a basic neutral parent pom with newest > plugins, or a BOM pom. Maybe there are other ideas. > Yes, neutral parent pom or BOM pom are to me good ways to improve Maven for > users: not changing default plugin versions in Maven core. > > Do I miss an aspect that should be taken into account? I've been through this path with Jenkins. My considered opinion is it is better to just upgrade. We provide a path to lock down versions. We have warned users for ages. An alternative could be to leverage the prerequisites value as a selector of the version defaults... though that would be re-enabling it for non-plugin packaging ;-) > > Regards, > > Hervé > > Le samedi 13 mai 2017, 23:11:05 CEST Robert Scholte a écrit : > > >> If you are saying that depending on default version is a bad practice > it > > >> actually means to me that this should change in the new major. > > >> Shouldn't it? > > > > > > this is a bad practice from a very long time, even in the Maven 2.x > > > time: what > > > should change more in next Maven version that would show it more, > without > > > breaking the magic that these defaults are used to? A warning message > > > proposing to add pluginManagement corresponding to current Maven > version > > > used? > > > Or propose a parent pom to add? > > > > IIRC up until Maven 2.0.8 there were no default plugin version, it was > > always selecting the latest when not specified. This was bad, because a > > new release of a plugin could suddenly make projects fail. > > Since Maven 2.0.9 there we started specifying default values to make > > everything more predictable. > > Right now we're also moving these information to the matching > > packaging-plugin, so the maven-jar-plugins specifies the > lifecycle-plugins > > and their versions. > > So in the end we should only specify the packaging-plugins in Maven core. > > Ideally these should not be part of maven-core, but that will it harder > to > > start using Maven. For that reason it will be likely that some plugins > > will still need to be specified with the Maven distribution. > > > > Robert > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Sent from my phone
