Hi Robert, I was investigating this issue long. The problem was with IDEA. Yesterday I installed new version 2019.2 and set JDK 1.7 as system JAVA_HOME but the project used JDK 1.8, see [1]. Suddenly, the maven-invoker-plugin used JAVA_HOME from the system and not from IDEA settings. It wasn't problem of invoker but IDEA which used system Java. I don't have explanation why it is so however Maven prented right Java [1].
After I used native commandline, the build has passed successfully. To confirm this, I used build-helper-maven-plugin, wrote BeanShell script, printed JAVA_HOME in the integration test "build-archetype". Altogether, our Jenkins is okay on apache/maven-resolver. The only problem was with my development tool! No worries in this case! [1]: Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 2019-04-04T21:00:29+02:00) Maven home: C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2019.2\plugins\maven\lib\maven3 Java version: 1.8.0_212, vendor: Oracle Corporation, runtime: C:\Program Files\Java\jdk1.8.0_212\jre On Fri, Jul 26, 2019 at 8:55 PM Robert Scholte <rfscho...@apache.org> wrote: > Hi Tibor, > > off topic, but step 3 should of course be verify... > > I can't reproduce it, nor can Jenkins@ASF, see > https://builds.apache.org/job/maven-box/job/maven-resolver/job/master/ > > Based on the exception I would expect that the runtime is Java 7, not > Java > 8. > Please verify the complete logfile, ensure it starts with mvn -V to see > the version output. > > thanks, > Robert > > > On Fri, 26 Jul 2019 16:41:58 +0200, Tibor Digana <tibordig...@apache.org> > > wrote: > > > 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 > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
