On May 12, 2017, at 4:50 AM, Michael Osipov <micha...@apache.org> 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: 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
