Le mardi 16 mai 2017, 22:20:35 CEST Stephen Connolly a écrit :
> On Tue 16 May 2017 at 22:40, Hervé BOUTEMY <[email protected]> wrote:
> > Le lundi 15 mai 2017, 07:20:08 CEST Stephen Connolly a écrit :
> > > On Sun 14 May 2017 at 08:51, Hervé BOUTEMY <[email protected]>
> > 
> > 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*
> > 
> > no, for these default plugin bindings, there is no warning, since the
> > default
> > binding defines a default version: that's the magic that happens with
> > minimal
> > poms.
> > 
> > The warning happens only when a new plugin is used without version.
> 
> Hmmm then that must have changed at some time because I am 99% certain that
> at some point in time there was a warning of plugins in the default
> lifecycle did not have a version specified...
> 
> But I recall at some point I lost the ability in the versions-m-p to detect
> that "normally" on the 3.x line (perhaps from 3.1.x onwards... I cannot
> recall)
as Robert explained, reproducibility was introduced in 2.0.9 (see MNG-3395, 
and the mecanism changed later to not be in super pom but in bindings): this 
removed the warning

just create a minimal pom with just groupId/artifactId/version and you'll see: 
no warning

> 
> I think we should restore those warnings then.
that's the whole complexity of ux: should we warn new users creating minimal 
poms? if not, when to warn them that minimal poms are just a fast track, that 
should rapidly be enhanced through a parent pom or an import?

Regards,

Hervé

> 
> > Then no, I don't see what "more complex ux" is there for new users.
> > This upgrade of default lifecycle plugin version looks to me just a big
> > misunderstanding on the expected benefit (or loss IMHO)
> > 
> > > > 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.
> > 
> > no, definitely not on default plugin bindings: this is a magic that not
> > many
> > people understand, and I don't think upgrading default version will
> > improve
> > this understanding.
> 
> Well if the warning was lost then yes, we would first need to restore the
> warning... then we can move to start upgrading again.
> 
> > > 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 ;-)
> > 
> > yes, this could be a solution: that would give a meaning to this
> > prerequisites
> > field in case of non-plugin packaging.
> > But it would be more complex than just providing a parent pom, or an
> > import
> > pom
> 
> Yes... and we've just told everyone to stop using it... but I do see it as
> a good solution.
> 
> > Regards,
> > 
> > Hervé
> > 
> > > > 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: [email protected]
> > > > For additional commands, e-mail: [email protected]
> > > > 
> > > > --
> > > 
> > > Sent from my phone
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> > 
> > --
> 
> Sent from my phone



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to