Quantcast

[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

[MNG-6169] Lifecycle/binding plugin version updates

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

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

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

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

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

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

michaelo
Am 2017-05-12 um 19:23 schrieb Chas Honton:
> How can the super pom be explicitly added to the project's pom?

Not necessary, the Super POM is in a JAR distributed with Maven and
automatically used.

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



---------------------------------------------------------------------
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
In reply to this post by michaelo
Can we declare explicitly that this pom does not inherit from super 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

Hervé BOUTEMY
In reply to this post by michaelo
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

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

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

>
> > 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?
what do you call "bloat"? and what do you call "a lot"? Is it better to
download plugin artifacts from network instead?

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

Any other view on this?

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]

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

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

michaelo
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/5c01864e44c7c96cac95545e8568acd044b6d7dc


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

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

>>> 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?
> what do you call "bloat"? and what do you call "a lot"? Is it better to
> download plugin artifacts from network instead?
>
>> 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?
> 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. 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).

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

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

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

mgainty
Good Morning Michael


any timeline on pom.xml creation for tomcat source distros?

i d/l 8.5.4

https://archive.apache.org/dist/tomcat/tomcat-8/v8.5.4/src/

and i see only 1 pom.xml for jdbc-pool


but I see 3 build.xml

find . name build.xml

./modules/jdbc-pool/build.xml
./res/deployer/build.xml
./webapps/ROOT/build.xml


for each attempt to track down a TC problem i am forced to create pom.xml from scratch

so I can build, package and deploy the war to locate the problem


I of course will help you *behind the scenes* for any assistance you may require


thanks,

Martin
______________________________________________

"why do you help the british?..in 1812 they burned your capitol"..The Great Escape


________________________________
From: Michael Osipov <[hidden email]>
Sent: Friday, May 12, 2017 6:58 PM
To: Maven Developers List
Subject: Re: [MNG-6169] Lifecycle/binding plugin version updates

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/5c01864e44c7c96cac95545e8568acd044b6d7dc
[https://avatars3.githubusercontent.com/u/573017?v=3&s=200]<https://github.com/apache/maven-integration-testing/commit/5c01864e44c7c96cac95545e8568acd044b6d7dc>

[MNG-6169] Lifecycle/binding plugin version updates · apache/maven-integration-testing@5c01864<https://github.com/apache/maven-integration-testing/commit/5c01864e44c7c96cac95545e8568acd044b6d7dc>
github.com
MNG-5895 and MNG-6090 with ArtifactResolutionException. Add dependencies Maven Resources Plugin 3.0.2 and Maven Surefire 2.2.0 to bootstrap's group 7.





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

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

>>> 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?
> what do you call "bloat"? and what do you call "a lot"? Is it better to
> download plugin artifacts from network instead?
>
>> 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?
> 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. 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).

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

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

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

Robert Scholte-6
In reply to this post by michaelo
On Sat, 13 May 2017 22:38:55 +0200, Hervé BOUTEMY <[hidden email]>  
wrote:

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

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

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

---------------------------------------------------------------------
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
Am 2017-05-15 um 09:20 schrieb Stephen Connolly:

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

We do not have two opposite opinions on this. What now, what to do with
the branch?

Michael



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

Loading...