I took time to launch the build many times and got to following conclusion:
- the only issue is about MAVEN_OPTS not being honoured in forked JVM - it's not related to a JDK version but mode Jenkins node: -> failing nodes: H24, H27, H28, H29, H33, H37 -> working nodes: H31, H32, H34, H44 to me, Maven core master branch is currently stable: the 4 ITs failing we see are caused by ASF Jenkins issues If someone wants to launch a release, I'm fully supportive Of course, if anybody has an idea on the root cause to the MAVEN_OPTS issue, I'm all ears open... Regards, Hervé Le samedi 20 juillet 2019, 19:53:05 CEST Tibor Digana a écrit : > Hello Herve, > > no problem. I am investigating in > https://builds.apache.org/job/maven-box/job/maven/job/EOL/ > the build is named after end-of-line because I have expected isues like > that. Only Jenkins Linux build fail, pls my last two commits in the branch > EOL. > > My commits correspond to ".gitattributes" file and Jenkinsfile. > In ".gitattributes" I set eol=LF and I am archiving the folder > "core-it-suite" in Jenkinsfile. > > It is strange that only Linux builds fail and thus there's is a kind of > platform dependency as it seems in this error. > I hope the archived ZIP file tells us more, e.g. logs at least. > > > Definitely something is wrong on Jenkins/Linux or in Jenkinsfile because > the build #22 was successful in > https://builds.apache.org/job/maven-box/job/maven/job/MNG-6294/ one month > ago, but I manually triggered #23 and I have got the same set of failed ITs > as we have in master today. > > Cheers > Tibor > > On Sat, Jul 20, 2019 at 7:25 PM Hervé BOUTEMY <[email protected]> wrote: > > I don't get where you want to go: there is no disagreement on reverting > > resolver from 1.4.0 to 1.3.3 > > > > the question is, once this revert has been done, about the 4 ITs failing > > [2]: > > master #242 linux-jdk7 / Run ITs Linux Java 7 > > 1. org.apache.maven.it > > .MavenITmng0553SettingsAuthzEncryptionTest.testitEncryption > > 2. org.apache.maven.it > > .MavenITmng0553SettingsAuthzEncryptionTest.testitBasic > > 3. org.apache.maven.it > > .MavenITmng4590ImportedPomUsesSystemPropertiesTest.testit > > 4. org.apache.maven.it.MavenITmng4747JavaAgentUsedByPluginTest.testit > > > > I investigated these ITs and found one common fact: they try to define > > MAVEN_OPTS (and are the only ones during that) > > > > verifier.setEnvironmentVariable( "MAVEN_OPTS", "...." ); > > > > and this does not seem to be transferred to the verifier execution > > > > I don't know yet why this does not work on some Jenkins nodes, trying to > > add a few additional output to see if I can get some hints... > > > > any idea welcome. > > > > Regards, > > > > Hervé > > > > [2] > > https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/ > > master/242/testReport/> > > Le samedi 20 juillet 2019, 12:48:27 CEST Tibor Digana a écrit : > > > I wrote in our chat that Maven Core fails randomly on random JDK > > > versions > > > due to maven-resolver:1.4.0. It was proved by: > > > > > > + Jenkins on Maven Core > > > + Jira MNG-6714 > > > + logical analysis of code in resolver. > > > > > > I wrote to Harald Wellmann that we should make code review together. > > > In my profession and company, the multithreading was my Java Advanced > > > expertize, so I am able to evaluate code which is thread safe and which > > > > is > > > > > not. Additionally, resolver:1.4.0 has logical problem even in single > > > > thread > > > > > which was proved by the branch where 11 unit tests failed on single > > > > thread > > > > > which of course must never happen. > > > > > > These things prove me to say that MRESOLVER-7 is not applicable in > > > production and we have to make code review together! > > > > > > Sorry to say, I can teach few devs with JSR-133 and thread safety > > > > regarding > > > > > Java Memory Model, and then the devs would probably understand why I > > > > found > > > > > issues in the code. Nevertheless still there are two problems with the > > > algorithm itself for whatever number of threads are executed: > > > > > > + one object is concurrently modified across multiple threads and the > > > object unexpectedly changes the state of the object > > > + there is one loop which resolves version but the last iteration wins, > > > > so > > > > > it loop looks to me ilogical and causes unnecessary object state > > > modifications > > > > > > > > > To be unbiased, all these things have to be clarified in PR on GitHub, > > > dicsussed, and changes have to be made in order to provide STABLE > > > > resolver. > > > > > That's all I can say in this issue. > > > Cheers > > > Tibor17 > > > > > > > > > > > > On Sat, Jul 20, 2019 at 12:25 PM Hervé BOUTEMY <[email protected]> > > > > > > wrote: > > > > little update on master branch runs in ASF Jenkins [1]: > > > > build #240: stupidly failed on a Git issue on a node > > > > > > > > then I launched build #241 *which worked fully*!!! > > > > > > > > to be sure of the stability, I relaunched the build, and build #242 > > > > failed > > > > > > on > > > > the 4 ITs on Linux JDK 7: really strange. FYI, I'm personally on > > > > Linux > > > > with > > > > Java 7 and I can't reproduce the issue. And the fact that Maven 3.6.0 > > > > branch > > > > fails on the same ITs, but sometimes on other configurations, makes me > > > > think > > > > there is an issue on some slave nodes on ASF Jenkins > > > > > > > > I integrated one little commit and build #243 still fails on the same > > > > 4 > > > > ITs > > > > > > > > > > > > I suspect it's an issue on ASF Jenkins, but I can't prove anything: I > > > > can't > > > > even tell which slave node run successfully for build #241 but which > > > > ones > > > > > > failed on next builds... > > > > > > > > Any idea on how to investigate? > > > > Should this postpone the 3.6.2 release or not? To me, MNG-6712 fixed > > > > the > > > > > > real > > > > issue, that was causing infinite loops during artifacts resolution. > > > > > > > > > > > > As a side note, I started by doing a lot of cleanup on old merged > > > > branches: it > > > > would be nice if everybody did its own cleanup when merging > > > > > > > > Regards, > > > > > > > > Hervé > > > > > > > > > > > > [1] > > > > https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/ > > > > > > master/ > > > > < > > > > https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job > > > > > > /master/>> > > > > > > > > Le mardi 16 juillet 2019, 23:22:22 CEST Tibor Digana a écrit : > > > > > Heads up!, > > > > > > > > > > I am investigating the build errors on Maven Core. > > > > > So I created three branches moved the HEAD backwards (i.e. git reset > > > > > > > > --hard > > > > > > > > > HEAD~12) and observed the outcome. > > > > > > > > > > I have investigated 29 commits. Not sure how far to go... > > > > > > > > > > `maven-resolver-1.3.3-reset-head-12` crashed with Linux + JDK 7, 8, > > > > 11, > > > > > > 12 > > > > > > > > > (16 ITs) > > > > > `maven-resolver-1.3.3-reset-head-14` crashed with Linux + JDK 7 and > > > > 8 (8 > > > > > > > ITs) > > > > > `maven-resolver-1.3.3-reset-head-29` crashed Linux JDK 8 (4 ITs) > > > > > > > > > > Always the ITs 0553, 4590, 4747 fail on several nodes. > > > > > Always related to Linux. > > > > > > > See the list of errors and branches: > > https://builds.apache.org/job/maven-box/job/maven/job/maven-resolver-1.3.3 > > > > > > -r> > > > > > > > > > eset-head-12/1/#showFailuresLink > > > > https://builds.apache.org/job/maven-box/job/maven/job/maven-resolver-1.3.3 > > > > > > -> reset-head-14/1/ > > > > https://builds.apache.org/job/maven-box/job/maven/job/maven-resolver-1.3.3 > > > > > > -> reset-head-29/1/ > > > > > > > > > From the MavenITmng0553SettingsAuthzEncryptionTest: > > > > > > > > > > [ERROR] Error executing Maven. > > > > > org.sonatype.plexus.components.sec.dispatcher.SecDispatcherException > > > > > : > > > > > > > java.io.FileNotFoundException: > > /home/jenkins/.m2/settings-security.xml > > > > > > (No > > > > > > > > > such file or directory) > > > > > > > > > > at org.sonatype.plexus.components.sec.dispatcher.SecUtil.read > > > > > > > > > > (SecUtil.java:69) > > > > > > > > > > at org.apache.maven.cli.MavenCli.encryption (MavenCli.java:920) > > > > > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:286) > > > > > at org.apache.maven.cli.MavenCli.main (MavenCli.java:192) > > > > > > > > > > [ERROR] Failed to execute goal on project test: Could not resolve > > > > > dependencies for project > > > > > org.apache.maven.its.mng0553:test:jar:1.0-SNAPSHOT: Failed to > > > > > collect > > > > > dependencies at org.apache.maven.its.mng0553:a:jar:0.1-SNAPSHOT: > > > > > Failed to read artifact descriptor for > > > > > org.apache.maven.its.mng0553:a:jar:0.1-SNAPSHOT: Could not transfer > > > > > artifact org.apache.maven.its.mng0553:a:pom:0.1-SNAPSHOT from/to > > > > > test > > > > > (http://localhost:32917/): Not authorized > > > > > > > From the MavenITmng4590ImportedPomUsesSystemPropertiesTest: > > expected:</home/jenkins/jenkins-slave/workspace/ven-resolver-1.3.3-reset-h > > > > > > ea> > > > > > > > > > d-29/test/core-it-suite/target/test-classes/mng-4590/pom.xml> but > > > > was:</home/jenkins/jenkins-slave/workspace/ven-resolver-1.3.3-reset-head-2 > > > > > > 9 > > > > > > > > > /test/core-it-suite/target/test-classes/mng-4590/${test.file}> > > > > > > > > > > > > > > > > > > > > From the MavenITmng4747JavaAgentUsedByPluginTest: > > > > > > > > > > junit.framework.AssertionFailedError > > > > > > > > > > at > > > > > > > > > > org.apache.maven.it > > > > > > > > .MavenITmng4747JavaAgentUsedByPluginTest.testit(MavenITm > > > > > > > > > ng4747JavaAgentUsedByPluginTest.java:63) > > > > > > > > --------------------------------------------------------------------- > > > > 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]
