On Sat, 13 May 2017 22:38:55 +0200, Hervé BOUTEMY <herve.bout...@free.fr>
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: dev-unsubscr...@maven.apache.org
>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
