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
