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: [email protected] > >>>> For additional commands, e-mail: [email protected] > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
