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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Robert Scholte-3
Is m-compiler-p on 3.6.1? please change to 3.5.1 until jigsaw stuff works correctly.


Verzonden vanaf Samsung Mobile.

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

Reply | Threaded
Open this post in threaded view
|

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.

Version has been downgraded.


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

Reply | Threaded
Open this post in threaded view
|

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

michaelo
In reply to this post by Robert Scholte-3
Am 2017-05-13 um 23:39 schrieb Michael Osipov:

> Am 2017-05-13 um 22:38 schrieb Hervé BOUTEMY:
>> 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...)
>
> I reran Maven 3.5.0, 3.3.9 on Core ITs master on two operating systems.
> Both pass. Then I ran 3.0.5, it fails just like you noticed. Except one
> failure, this is due to the embedded mode. Several ITs are not
> wellsuited for embedded mode (single VM).
>
> The single in 3.0.5 is in MavenITmng0947OptionalDependencyTest. You
> might remember that I have done recently some improvements to "optional"
> in Core as well es to Core IT Support plugins: MNG-6229. It now payed
> off. The optional flag was missing on the dep tree output, so the test
> was impcomplete. Now, an issue has been detected in 3.0.5 or the IT itself:
>
> Actual:
>> [INFO] [MAVEN-CORE-IT-LOG] Dumping artifact list:
>> D:\Entwicklung\Projekte\maven-integration-testing\core-it-suite\target\test-classes\mng-0947\target\compile.txt
>>
>> [INFO] [MAVEN-CORE-IT-LOG]   org.apache.maven.its.mng0947:e:jar:0.1
>> (optional)
>> [INFO] [MAVEN-CORE-IT-LOG]   org.apache.maven.its.mng0947:d:jar:0.1
>> [INFO]
>> [INFO] --- maven-it-plugin-dependency-resolution:2.1-SNAPSHOT:runtime
>> (test) @ consumer ---
>> [INFO] [MAVEN-CORE-IT-LOG] Dumping artifact list:
>> D:\Entwicklung\Projekte\maven-integration-testing\core-it-suite\target\test-classes\mng-0947\target\runtime.txt
>>
>> [INFO] [MAVEN-CORE-IT-LOG]   org.apache.maven.its.mng0947:c:jar:0.1
>> [INFO] [MAVEN-CORE-IT-LOG]   org.apache.maven.its.mng0947:e:jar:0.1
>> (optional)
>> [INFO] [MAVEN-CORE-IT-LOG]   org.apache.maven.its.mng0947:d:jar:0.1
>> [INFO]
>> [INFO] --- maven-it-plugin-dependency-resolution:2.1-SNAPSHOT:test
>> (test) @ consumer ---
>> [INFO] [MAVEN-CORE-IT-LOG] Dumping artifact list:
>> D:\Entwicklung\Projekte\maven-integration-testing\core-it-suite\target\test-classes\mng-0947\target\test.txt
>>
>> [INFO] [MAVEN-CORE-IT-LOG]   org.apache.maven.its.mng0947:c:jar:0.1
>> [INFO] [MAVEN-CORE-IT-LOG]   org.apache.maven.its.mng0947:e:jar:0.1
>> (optional)
>> [INFO] [MAVEN-CORE-IT-LOG]   org.apache.maven.its.mng0947:d:jar:0.1
>
> Expected:
>>         List<String> compile = verifier.loadLines(
>> "target/compile.txt", "UTF-8" );
>>         assertTrue( compile.toString(), compile.contains(
>> "org.apache.maven.its.mng0947:d:jar:0.1 (optional)" ) );
>>         assertTrue( compile.toString(), compile.contains(
>> "org.apache.maven.its.mng0947:e:jar:0.1 (optional)" ) );
>>         assertEquals( 2, compile.size() );
>>
>>         List<String> runtime = verifier.loadLines(
>> "target/runtime.txt", "UTF-8" );
>>         assertTrue( runtime.toString(), runtime.contains(
>> "org.apache.maven.its.mng0947:c:jar:0.1" ) );
>>         assertTrue( runtime.toString(), runtime.contains(
>> "org.apache.maven.its.mng0947:d:jar:0.1 (optional)" ) );
>>         assertTrue( runtime.toString(), runtime.contains(
>> "org.apache.maven.its.mng0947:e:jar:0.1 (optional)" ) );
>>         assertEquals( 3, runtime.size() );
>>
>>         List<String> test = verifier.loadLines( "target/test.txt",
>> "UTF-8" );
>>         assertTrue( test.toString(), test.contains(
>> "org.apache.maven.its.mng0947:c:jar:0.1" ) );
>>         assertTrue( test.toString(), test.contains(
>> "org.apache.maven.its.mng0947:d:jar:0.1 (optional)" ) );
>>         assertTrue( test.toString(), test.contains(
>> "org.apache.maven.its.mng0947:e:jar:0.1 (optional)" ) );
>>         assertEquals( 3, test.size() );
>
> I need to have a closer look at it through the Maven versions.

Tackled it. Any objections to merge
44ae63380768e53fab11ffb73131f201b268ed81 on Core ITs?

Michael



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

Reply | Threaded
Open this post in threaded view
|

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

Hervé BOUTEMY
I don't understand what changed in Maven 3.1.0-alpha-1 that changed the
behaviour: did you find which issue was fixed?

Adding a pointer to that issue as comment (and not only in git commit message)
would be useful before merging so that this change is understood when reading
the code

thanks for digging into this

Regards,

Hervé

Le dimanche 14 mai 2017, 00:25:10 CEST Michael Osipov a écrit :

> > I need to have a closer look at it through the Maven versions.
>
> Tackled it. Any objections to merge
> 44ae63380768e53fab11ffb73131f201b268ed81 on Core ITs?
>
> 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
|

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

Hervé BOUTEMY
In reply to this post by Robert Scholte-3
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?

To me, changing default plugin versions lowers reproducibility.
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.

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?

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]

Reply | Threaded
Open this post in threaded view
|

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

michaelo
In reply to this post by Hervé BOUTEMY
Am 2017-05-14 um 09:33 schrieb Hervé BOUTEMY:
> I don't understand what changed in Maven 3.1.0-alpha-1 that changed the
> behaviour: did you find which issue was fixed?

Unfortunately not. Issue titles weren't helpful, commit messages also. I
assume this is an Aether update.

> Adding a pointer to that issue as comment (and not only in git commit message)
> would be useful before merging so that this change is understood when reading
> the code

Did update JIRA issues. I will go ahead and merge the commit.

> Regards,
>
> Hervé
>
> Le dimanche 14 mai 2017, 00:25:10 CEST Michael Osipov a écrit :
>>> I need to have a closer look at it through the Maven versions.
>>
>> Tackled it. Any objections to merge
>> 44ae63380768e53fab11ffb73131f201b268ed81 on Core ITs?
>>
>> 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]