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.
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?
I think a warning for < 4.0 to fix the version would be best and have it
fail in 4.0 if the version of the lifecycle plugin is not provided.
Moreover, the fixed version in the embedded XMLs would need to go.
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
No, it is not.
[...]
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.
I see two benefits:
1. People know that the default versions passes all ITs
2. We have a chance to test the plugins through the entire chain and
detect regressions. I hardly believe that most of us do test a plugin in
the Core IT chain.
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!
That's the best benefit for me!
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
