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