Quantcast

Re: [MNG-6169] Lifecycle/binding plugin version updates

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [MNG-6169] Lifecycle/binding plugin version updates

michaelo
Am 2017-05-11 um 22:46 schrieb Robert Scholte:
> Is m-compiler-p on 3.6.1? please change to 3.5.1 until jigsaw stuff works correctly.

Yes, it is 3.5.1. I will downgrade to 3.5.1 shortly.


Michael

> <div>-------- Oorspronkelijk bericht --------</div><div>Van: Michael Osipov <[hidden email]> </div><div>Datum:11-05-2017  22:30  (GMT+01:00) </div><div>Aan: Maven Developers List <[hidden email]> </div><div>Onderwerp: [MNG-6169] Lifecycle/binding plugin version updates </div><div>
> </div>Who seconds MNG-6169 for 3.5.1? I have a fully working branch
> (MNG-6169_2/not-updated-MJAR-MCOMPILER) passing all ITs on Windows 10
> and FreeBSD 10.3-RELEASE.
>
> Jenkins build is flaky with notorious file://target/null artifact not found.
>
> Some bindings haven't been updated because they cause several ITs to
> fail (regressions). I will report them separately.
>
>
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [MNG-6169] Lifecycle/binding plugin version updates

Hervé BOUTEMY
Jenkins build is not flaky: it is strict on dependency resolution from cache,
which is an intent, not a bug

that's why I don't like changing default plugins versions:

1. depending on default plugins versions is a bad practice: IMHO, having old
plugins helps people know that they should not rely on it

2. people who do a "dependency:go-offline" with a previous Maven version but run
offline with updated Maven version will see their build fail and report about
dependency:go-offline not being reliable, which is technically not true, but is
sensitive to Maven version (something that is hard to explain)

On the first objection, it's a question of choice on how to promote the good
practice about explicitely choosing your plugins versions

On the second objection, I had an idea of Maven core improvement that would fix
the go-offline dependency on Maven version used: what if Maven core distribution
did contain a (read-only) local repo with default plugins already resolved?

With such a feature, go-offline would not be dependant on Maven version used
(starting from the Maven version that has this pre-built repo). And user would
better see the default dependencies by looking at this pre-builot repo =
something I'm sure they will do (but they don't have a look at lifecycle
definition files, which are opaque for them)

I didn't have time to work on implementing this idea, I suppose this would
just require a new default repository with file://${maven.home}/default-
plugins/ url, and to fill this repo at build time with appropriate go-offline

WDYT?

Regards,

Hervé

Le jeudi 11 mai 2017, 22:30:43 CEST Michael Osipov a écrit :

> Who seconds MNG-6169 for 3.5.1? I have a fully working branch
> (MNG-6169_2/not-updated-MJAR-MCOMPILER) passing all ITs on Windows 10
> and FreeBSD 10.3-RELEASE.
>
> Jenkins build is flaky with notorious file://target/null artifact not found.
>
> Some bindings haven't been updated because they cause several ITs to
> fail (regressions). I will report them separately.
>
>
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [MNG-6169] Lifecycle/binding plugin version updates

Chas Honton
How can the super pom be explicitly added to the project's pom?

Chas

> On May 12, 2017, at 4:50 AM, Michael Osipov <[hidden email]> wrote:
>
>> Am 2017-05-12 um 08:25 schrieb Hervé BOUTEMY:
>> Jenkins build is not flaky: it is strict on dependency resolution from cache,
>> which is an intent, not a bug
>
> This pretty much explains why a lot of ITs fail here at work with a empty repo. I will to work this through.
>
>> that's why I don't like changing default plugins versions:
>>
>> 1. depending on default plugins versions is a bad practice: IMHO, having old
>> plugins helps people know that they should not rely on it
>
> This basically means that people would need to provide versions explicitly in the POMs starting with Maven 4. Looks like a lot of hassle, doesn't it? I'd better see this in the Super POM rather embedded in a JAR.
>
>> 2. people who do a "dependency:go-offline" with a previous Maven version but run
>> offline with updated Maven version will see their build fail and report about
>> dependency:go-offline not being reliable, which is technically not true, but is
>> sensitive to Maven version (something that is hard to explain)
>
> Pretty good point. We should actually ad this information to the goal doc. This will also fail if your change your POM.
>
>> On the first objection, it's a question of choice on how to promote the good
>> practice about explicitely choosing your plugins versions
>>
>> On the second objection, I had an idea of Maven core improvement that would fix
>> the go-offline dependency on Maven version used: what if Maven core distribution
>> did contain a (read-only) local repo with default plugins already resolved?
>>
>> With such a feature, go-offline would not be dependant on Maven version used
>> (starting from the Maven version that has this pre-built repo). And user would
>> better see the default dependencies by looking at this pre-builot repo =
>> something I'm sure they will do (but they don't have a look at lifecycle
>> definition files, which are opaque for them)
>>
>> I didn't have time to work on implementing this idea, I suppose this would
>> just require a new default repository with file://${maven.home}/default-
>> plugins/ url, and to fill this repo at build time with appropriate go-offline
>
> Sounds like a good idea but would produce a lot of bloat, wouldn't it? All plugin dependency trees. This should be configurable in settings.xml and MDEP should provide a goal to populate such a repo.
> I am afraid that no one will pick this up anytime soon.
>
> Do you know completely reject the issue to be merged?
>
> Michael
>
>> Le jeudi 11 mai 2017, 22:30:43 CEST Michael Osipov a écrit :
>>> Who seconds MNG-6169 for 3.5.1? I have a fully working branch
>>> (MNG-6169_2/not-updated-MJAR-MCOMPILER) passing all ITs on Windows 10
>>> and FreeBSD 10.3-RELEASE.
>>>
>>> Jenkins build is flaky with notorious file://target/null artifact not found.
>>>
>>> Some bindings haven't been updated because they cause several ITs to
>>> fail (regressions). I will report them separately.
>>>
>>>
>>> Michael
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [MNG-6169] Lifecycle/binding plugin version updates

michaelo
In reply to this post by Hervé BOUTEMY
Am 2017-05-12 um 08:25 schrieb Hervé BOUTEMY:
> Jenkins build is not flaky: it is strict on dependency resolution from cache,
> which is an intent, not a bug

Traced down last missing dependencies and added them to Bootstrap IT.
Branch MNG-6169 created on the Core ITs.

Michael



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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [MNG-6169] Lifecycle/binding plugin version updates

Hervé BOUTEMY
In reply to this post by michaelo
Le samedi 13 mai 2017, 00:58:45 CEST Michael Osipov a écrit :

> Am 2017-05-13 um 00:30 schrieb Hervé BOUTEMY:
> > Le vendredi 12 mai 2017, 13:50:37 CEST Michael Osipov a écrit :
> >> Am 2017-05-12 um 08:25 schrieb Hervé BOUTEMY:
> >>> Jenkins build is not flaky: it is strict on dependency resolution from
> >>> cache, which is an intent, not a bug
> >>
> >> This pretty much explains why a lot of ITs fail here at work with a
> >> empty repo. I will to work this through.
> >
> > beware to not make the ITs fail with previous Maven versions
>
> All I did is this:
> https://github.com/apache/maven-integration-testing/commit/5c01864e44c7c96ca
> c95545e8568acd044b6d7dc
ok, just tested with Maven 3.0.5: this does not add more failures (notice that
existing failures show we already did some mistakes in the past regarding some
updated ITs...)

> >>> that's why I don't like changing default plugins versions:
> >>>
> >>> 1. depending on default plugins versions is a bad practice: IMHO, having
> >>> old plugins helps people know that they should not rely on it
> >>
> >> This basically means that people would need to provide versions
> >> explicitly in the POMs starting with Maven 4.
> >
> > ??? Why are you talking about Maven 4?
>
> 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?

> >> Looks like a lot of
> >> hassle, doesn't it? I'd better see this in the Super POM rather embedded
> >> in a JAR.
> >
> > ??? "embedded in a JAR"? what did I say that lead to something like this?
>
> I assumed that your idea is rather nothing this up to the Super POM:
> ./maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xm
the super pom is in Maven: anything in Maven won't change that default will be
dependent on Maven version used, which is not good for reproducibility

[...]

> >> Do you know completely reject the issue to be merged?
> >
> > I'd like to have us understand each other:
> > - what do you expect to win?
> > - what do we loose?
> > I know doing this update is easy to do and corresponds to a lot of good
> > intentions on giving latest of everything for lazy users: but the
> > consequences are IMHO not so positive and are for the moment
> > misunderstood/ignored My position is not definitive, the discussion on
> > evaluating with multiple many eyes if this change is really good or not,
> > and goot at what, will make my final opinion on this: but sure, for the
> > moment, I'm not convinced this update goes in a good direction
>
> It wasn't easy. I invested quite some time to make all ITs pass.
yes, changing the versions in Maven is easy, but updating ITs and checking
that everything works better is harder: once again, I don't see the value to
updating these default values, since people should define their own plugins
versions in their pom. But I see value of having the same plugins versions in
every Maven 3.x release, to have some de-facto reproducibility.

> Some
> plugins weren't even updated because they cause regressions in ITs which
> I still haven't investigated yet. Some even cause zlib failures in
> native code (known JVM issue due to bad code).
uh!

Regards,

Hervé

>
> >> Michael
> >>
> >>> Le jeudi 11 mai 2017, 22:30:43 CEST Michael Osipov a écrit :
> >>>> Who seconds MNG-6169 for 3.5.1? I have a fully working branch
> >>>> (MNG-6169_2/not-updated-MJAR-MCOMPILER) passing all ITs on Windows 10
> >>>> and FreeBSD 10.3-RELEASE.
> >>>>
> >>>> Jenkins build is flaky with notorious file://target/null artifact not
> >>>> found.
> >>>>
> >>>> Some bindings haven't been updated because they cause several ITs to
> >>>> fail (regressions). I will report them separately.
> >>>>
> >>>>
> >>>> Michael
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: [hidden email]
> >>>> For additional commands, e-mail: [hidden email]
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [MNG-6169] Lifecycle/binding plugin version updates

stephenconnolly
On Sun 14 May 2017 at 08:51, Hervé BOUTEMY <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
Sent from my phone
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [MNG-6169] Lifecycle/binding plugin version updates

Hervé BOUTEMY
Le lundi 15 mai 2017, 07:20:08 CEST Stephen Connolly a écrit :

> On Sun 14 May 2017 at 08:51, Hervé BOUTEMY <[hidden email]> 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.

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.

>
> 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

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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> > --
>
> Sent from my phone



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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [MNG-6169] Lifecycle/binding plugin version updates

stephenconnolly
On Tue 16 May 2017 at 22:40, Hervé BOUTEMY <[hidden email]> wrote:

> Le lundi 15 mai 2017, 07:20:08 CEST Stephen Connolly a écrit :
> > On Sun 14 May 2017 at 08:51, Hervé BOUTEMY <[hidden email]>
> 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)

I think we should restore those warnings then.


> 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > > --
> >
> > Sent from my phone
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
Sent from my phone
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [MNG-6169] Lifecycle/binding plugin version updates

Hervé BOUTEMY
Le mardi 16 mai 2017, 22:20:35 CEST Stephen Connolly a écrit :

> On Tue 16 May 2017 at 22:40, Hervé BOUTEMY <[hidden email]> wrote:
> > Le lundi 15 mai 2017, 07:20:08 CEST Stephen Connolly a écrit :
> > > On Sun 14 May 2017 at 08:51, Hervé BOUTEMY <[hidden email]>
> >
> > 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: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > > --
> > >
> > > Sent from my phone
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> > --
>
> Sent from my phone



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

Loading...