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 <herve.bout...@free.fr>
> 
> 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: 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

Reply via email to