Hi Clemens, Does JDK 7u80 work for you on fresh empty local repo?
It does not for me on Surefire project! The Maven fails downloading the artifacts from Maven Central this month. Before the build was okay. So I issued the ticket https://issues.apache.org/jira/browse/INFRA-18775 and I hope that our INFRA team will accept Zulu JDK from Azul Systems. The Zulu JDK is being maintained quite long. Of course the best decision would be to have extended support from the Oracle and use latest JDK but I am sceptical about it due to the Oracle's LTS is not free. Cheers Tibor On Tue, Jul 23, 2019 at 7:34 PM Robert Scholte <[email protected]> wrote: > 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 <[email protected]> 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: [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] > >
