Hi Tibor,
with this system property set it works with JDK 7.
Why is it a pre-requisite? It works with JDK 7 Update 80 that has no
backport for TLS 1.2. It came with Update 131 [1].
Are you simply running all the IT on your side with this system property
set when using JDK 7? What Update of JDK 7 are you normally using for ITs?
So this property was already around when IT for MRELEASE-459 was
written? That would explain it.
One mor question, please: How would I have been able to avoid all this
noise in the dev-mail-group? Where could I have read about this system
property? Is it documented somewhere?
Cheers, Clemens
[1]
https://stackoverflow.com/questions/39157422/how-to-enable-tls-1-2-in-java-7
Am 14.07.2019 um 18:58 schrieb Tibor Digana:
Did you already run the build like this on J7?
mvn verify -P run-its -Dhttps.protocols=TLSv1.2
and you have got those errors as in previous email?
Cheers
Tibor
On Sun, Jul 14, 2019 at 6:32 PM Clemens Quoss <clem...@quoss.de> wrote:
Hi Tibor,
by looking further into it I noticed this:
MRELEASE-459/build.log (JDK 7):
...
[DEBUG] Additional arguments: -Dhttps.protocols=null -P custom-release
-DperformRelease=true -f pom.xml
...
MRELEASE-459/build.log (JDK 8):
...
[DEBUG] Additional arguments: -P custom-release -DperformRelease=true -f
pom.xml
...
Additional arg '-Dhttps.protocols=null' appears with JDK 7 (or vanishes
with JDK 8, your choice).
This seems to break the match in verify.groovy - i am not an regexp expert:
...
def addArgsExpr = /\Q[DEBUG] Additional arguments:
\E(?:-Dhttps.protocols=TLSv1.2 )?-P(.+)\Q-DperformRelease=true -f
pom.xml\E/
...
But: where does this additonal arg come from in the first place? Should
the match be re-written?
Cheers,
Clemens
Am 14.07.2019 um 18:22 schrieb Tibor Digana:
Hi Clemens,
I think you are right, I also have to add -Dhttps.protocols=TLSv1.2 in to
CLI when using J7.
The Jenkinsfile does it [1] already but we should investigate the ITs and
add TLS in CLI of the ITs as well unless it's in there.
[1]:
https://gitbox.apache.org/repos/asf?p=maven-jenkins-lib.git;a=blob;f=vars/asfMavenTlpStdBuild.groovy;h=b0d1d0d2d70172e03754e1666c78aa13d0d38b34;hb=HEAD#l65
Tibor
On Sun, Jul 14, 2019 at 11:52 AM Clemens Quoss <clem...@quoss.de> 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
