Hi Robert, I have very similar issue in apache/maven-resolver on my PC. I don't know if the root cause is identical with the one you described in your email regarding the parameter mavenOpts and shared environment variable but I am sure you can reproduce it too. These are my reprosteps:
1. clone the project apache/maven-resolver 2. use JDK 1.8 in JAVA_HOME 3. run the build "mvn install -P run-its" The build fails with: [ERROR] The following builds failed: The following builds failed: * build-and-run-its\pom.xml * build-archetype\pom.xml * build-ignore-eol\pom.xml When you open maven-archetype-plugin/target/it/projects/build-and-run-its/build.log you will have the error which is typical for JDK7. The issue is that I executed the build with JDK8. "Received fatal alert: protocol_version". Here is my console output: [INFO] [INFO] --------------------------------[ jar ]--------------------------------- [INFO] [INFO] Downloading from local.central: file:///C:/vcs/github/maven-archetype/maven-archetype-plugin/target/local-repo/org/apache/maven/plugins/maven-resources-plugin/2.6/maven-resources-plugin-2.6.pom [INFO] [INFO] Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-resources-plugin/2.6/maven-resources-plugin-2.6.pom [INFO] [INFO] ------------------------------------------------------------------------ [INFO] [INFO] BUILD FAILURE [INFO] [INFO] ------------------------------------------------------------------------ [INFO] [INFO] Total time: 1.286 s [INFO] [INFO] Finished at: 2019-07-26T14:15:54+02:00 [INFO] [INFO] ------------------------------------------------------------------------ [INFO] [ERROR] Plugin org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-resources-plugin:jar:2.6: Could not transfer artifact org.apache.maven.plugins:maven-resources-plugin:pom:2.6 from/to central (https://repo.maven.apache.org/maven2): Received fatal alert: protocol_version -> [Help 1] [INFO] org.apache.maven.plugin.PluginResolutionException: Plugin org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-resources-plugin:jar:2.6 [INFO] at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve (DefaultPluginDependenciesResolver.java:117) [INFO] at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor (DefaultMavenPluginManager.java:182) On Fri, Jul 26, 2019 at 1:23 PM Robert Scholte <rfscho...@apache.org> wrote: > Looks like the same issue as there was with the maven site plugin: the > failing it was using mavenOpts as well. > I'm pretty sure that mavenOpts is not isolated and can be changed by any > other process on the same server. > Instead one should be using test.properties to pass those properties, > which are isolated. > > Robert > > On Thu, 25 Jul 2019 14:20:53 +0200, Tibor Digana <tibordig...@apache.org> > > wrote: > > > Just one remark from me: > > I have got successful build with Surefire but it is strange because I > > cannot explain why my change did it successful ;-) - pls help to > explain > > it: > > https://builds.apache.org/job/maven-box/job/maven-surefire/job/TLS1.2/ > > > > Before I did this in the configuration of "maven-invoker-plugin": > > <mavenOpts>-Dhttps.protocols=TLSv1.2</mavenOpts> > > and the the build always failed on JDK7. > > > > Then I pushed a branch named "TLS1.2" and added system property: > > The build is successful now!. But why? The Maven JVM is a forked process, > > isn't it? > > Both, the MAVEN_OPTS and system properties should go to the CLI > > arguments, > > right? So there should not be any difference but obviously there is! > > > > <properties> > > <https.protocols>TLSv1.2</https.protocols> > > </properties> > > > > Thx for clarification in advance! > > Tibor > > > > > > On Thu, Jul 25, 2019 at 8:38 AM Robert Scholte <rfscho...@apache.org> > > wrote: > > > >> I've invested a lot of time when the TLSv1.2 became a requirement and > >> this > >> is the best solution: > >> - pass https.protocols to plugin configuration when a new JVM is started > >> (if it is not set, it'll be ignored) > >> - this is based on the fact that if you have a clean repo you must pass > >> this value anyway. > >> - this property must be forward compatible: if TLS1.3 is the new > >> default, > >> we should never reduce it to TLSv1.2 > >> > >> If the UK mirror still allows TLSv1.1, then *that* should be fixed, not > >> the current configuration of plugins. > >> > >> thanks, > >> Robert > >> > >> On Wed, 24 Jul 2019 23:37:31 +0200, Clemens Quoss <clem...@quoss.de> > >> wrote: > >> > >> > Hi Robert, > >> > well it is already handled in the POM only for JDK 7: > >> > > >> > ... > >> > <profile> > >> > <id>jdk7</id> > >> > <activation> > >> > <jdk>(,1.7]</jdk> > >> > </activation> > >> > <build> > >> > <plugins> > >> > <plugin> > >> > <groupId>org.apache.maven.plugins</groupId> > >> > <artifactId>maven-invoker-plugin</artifactId> > >> > <configuration> > >> > <properties combine.children="merge"> > >> > <https.protocols>${https.protocols}</https.protocols> > >> > <arguments>-Dhttps.protocols=${https.protocols}</arguments> > >> > </properties> > >> > </configuration> > >> > </plugin> > >> > </plugins> > >> > </build> > >> > </profile> > >> > ... > >> > > >> > Of course, this only takes care of when you release something with the > >> > plugin using JDK 7. When building maven-release itself you will have > >> to > >> > provide the system property for JDK 7, but not when using UK mirror > >> ;-) > >> > > >> > Cheers, Clemens > >> > > >> > Am 24.07.2019 um 23:20 schrieb Robert Scholte: > >> >> Hi Clemens, > >> >> > >> >> We need to stay as close as possible to the real world. > >> >> With JDK8+ it should work without its being set, so the preferred way > >> >> it to execute it without the value being set. > >> >> And this way, once we must move TLS 1.3 we don't have to change all > >> our > >> >> tests. > >> >> Here's how we do it with our Jenkins script[1], only activate it for > >> >> Java 7. > >> >> > >> >> Robert > >> >> > >> >> [1] > >> >> > >> > https://github.com/apache/maven-jenkins-lib/blob/master/vars/asfMavenTlpPlgnBuild.groovy#L128-L131 > >> >> > >> >> On Wed, 24 Jul 2019 23:03:22 +0200, Clemens Quoss <clem...@quoss.de> > >> >> wrote: > >> >> > >> >>> Hi Robert, > >> >>> if TLSv1.2 is needed, then why not put it explicitly into the pom in > >> >>> line 266 [0] instead of using ${https.protocols}? > >> >>> > >> >>> Cheers, Clemens > >> >>> > >> >>> [0] > >> >>> > >> > https://github.com/apache/maven-release/blob/a94c76f77ef8df1b82e9eef370412ce9b23083a0/maven-release-plugin/pom.xml#L266 > >> >>> > >> >>> Am 23.07.2019 um 19:33 schrieb Robert Scholte: > >> >>>> Hi Clemens, > >> >>>> > >> >>>> please see > >> >>>> > >> > https://central.sonatype.org/articles/2018/May/04/discontinued-support-for-tlsv11-and-below/ > >> >>>> We'll need to contact Sonatype and verify if they included > >> >>>> http://uk.maven.org/maven2/ as well (they should...) > >> >>>> > >> >>>> However, AFAIK nowadays there's no need anymore to explicitly refer > >> >>>> to uk, it is already handled by Central CDN > >> >>>> > >> >>>> thanks, > >> >>>> Robert > >> >>>> On 23-7-2019 00:01:06, Clemens Quoss <clem...@quoss.de> wrote: > >> >>>> Hi Robert, > >> >>>> thanks for the insight. Shouldn't it fail with JDK 7 Update 80 > >> even > >> >>>> with this parameter since the backport for TLSv1.2 came with Update > >> >>>> 95 [0]? > >> >>>> Since when does this requirement exist? Just checked it: I'm > >> using > >> >>>> UK > >> >>>> mirror [1]. This works without TLSv1.2. Maybe thats why i didn't > >> >>>> noticed before. > >> >>>> But we had problem at work contacting the Atlassian Repo from our > >> >>>> Nexus > >> >>>> that ran with JDK 7 Update 80. In that case we switched back to > >> JDK 6 > >> >>>> Update 211. > >> >>>> > >> >>>> Cheers, Clemens > >> >>>> > >> >>>> [0] > >> >>>> > >> > https://stackoverflow.com/questions/49523052/how-to-enable-tlsv1-2-in-java-7u80-client > >> > >> >>>> [1] http://uk.maven.org/maven2/ > >> >>>> > >> >>>> Am 22.07.2019 um 23:45 schrieb Robert Scholte: > >> >>>>> The plugin is indeed still Java 7 compatible, but that means you > >> must > >> >>>>> execute it with -Dhttps.protocols=TLSv1.2 when building it with > >> JDK > >> >>>>> 7, > >> >>>>> otherwise it'll fail because this is a requirement when > >> downloading > >> >>>>> from Central. > >> >>>>> Our CI server scripts already add this argument when running with > >> >>>>> Java > >> >>>>> 7, on your local machine it must be done by hand. This is not > >> >>>>> restricted to the integration tests. Try to remove your local repo > >> >>>>> and > >> >>>>> start any project running with Maven and Java 7, it'll fail very > >> >>>>> fast, > >> >>>>> i.e. by the first plugin. > >> >>>>> > >> >>>>> thanks, > >> >>>>> Robert > >> >>>>> > >> >>>>> On Sun, 14 Jul 2019 11:52:15 +0200, Clemens Quoss > >> >>>>> wrote: > >> >>>>> > >> >>>>>> Hello everyone, > >> >>>>>> > >> >>>>>> I have provided a PR for MRELEASE-229 [1] and added some JUnit > >> tests > >> >>>>>> recently. > >> >>>>>> > >> >>>>>> Now I was wondering if i should provide an IT, too, and had a > >> look > >> >>>>>> into it: > >> >>>>>> > >> >>>>>> Running > >> >>>>>> > >> >>>>>> mvn verify -Prun-its > >> >>>>>> > >> >>>>>> with Maven 3.6.1 and JDK 7 Update 80 fails: > >> >>>>>> > >> >>>>>> ... > >> >>>>>> > >> >>>>>> [INFO] Building: projects\perform\MRELEASE-459\pom.xml > >> >>>>>> [INFO] run post-build script verify.groovy > >> >>>>>> [INFO] The post-build script did not succeed. assert > >> >>>>>> matcher.find() > >> >>>>>> | | > >> >>>>>> | false > >> >>>>>> java.util.regex.Matcher[pattern=\Q[DEBUG] Additional > >> >>>>>> arguments: \E(?:-Dhttps.protocols=TLSv1.2 > >> >>>>>> )?-P(.+)\Q-DperformRelease=true -f pom.xml\E region=0,154745 > >> >>>>>> lastmatch=] > >> >>>>>> [INFO] projects\perform\MRELEASE-459\pom.xml > >> ............ > >> >>>>>> FAILED (10.4 s) > >> >>>>>> > >> >>>>>> ... > >> >>>>>> > >> >>>>>> IMHO it has something to do with TLSv1.2 not being backported > to > >> JDK > >> >>>>>> 7 Update 80. But i may be wrong. > >> >>>>>> > >> >>>>>> With JDK 8 Update 212 the tests run successfully. > >> >>>>>> > >> >>>>>> My question is: Should the IT still run with JDK 7? I thought > >> so > >> >>>>>> since maven-release can still be build with it. If some > >> versions of > >> >>>>>> JDKs are not capable of being used for IT, shouldn't the IT run > >> fail > >> >>>>>> fast (by enforcing the eligible versions)? > >> >>>>>> > >> >>>>>> That was one question I have now redarding the ITs of > >> maven-release. > >> >>>>>> I post my other questions in separate mails. > >> >>>>>> > >> >>>>>> Regards, > >> >>>>>> > >> >>>>>> Clemens > >> >>>>>> > >> >>>>>> [1] https://github.com/apache/maven-release/pull/29 > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> --------------------------------------------------------------------- > >> >>>>>> 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 > >
