Hi Tibor,
will look at the Readmes, and see what I can do, though I didn't came to
look at them in the first place.
Not sure what you meant with the CLI documentation, though. Maybe you
can help me with that in direct mail.
As to the Java SE roadmaps [0]:
JDK 7 Update 80 was the last free update (non-premier / non-extended).
For paying customers Oracle has extended
support until end of july 2022. Do not ask me about the difference
between premier and extended support, but you have
to have an Oracle Customer Support Identifier (CSI) connected to your
Oracle Account to get the further updates.
My company account is connected to our companies CSI and i am eligible
to download these versions. For instance,
we are still using JDK 6 Update 211 in our productive environments.
Update 211 being the last one issued (extended
support ended after December 2018). But we are migrating ;-)
But i think not only paying but also non-profit customers like Apache
can get extended support. And i suppose someone
must be eligible at Apache, even at maven, to use extended support.
Why do i think this? Look at the bottom of this
page: [1] It states the Surefire Report was build using JDK 7 Update 181.
While digging up this page again for reference I found a lot of
interesting links on infrastructure, the CI ecosystem and IT
and a lot of other stuff I will now start reading (should have done that
before, i know ...)
Just one last word as to the system property (https.protocols). Since
the backport for JDK 7 was in Update 131, there
is no need to provide it in Update 80. But I think there is logic
hidden somewhere propagating this parameter without checking
if it is set, so resulting in -Dhttps.protocols=_null_ (only for jdk 7).
Cheers, Clemens
[0] https://www.oracle.com/technetwork/java/java-se-support-roadmap.html
[1] https://maven.apache.org/core-its/core-it-suite/
Am 15.07.2019 um 02:59 schrieb Tibor Digana:
Hi Clemens,
Simply I am using JDK 1.7.0_80-b15 and our Jenkins also has this version.
I could not find and download later update of JDK 1.7 neither the Update
131.
So that's maybe the reason why I recommended to use TLS 1.2 in the system
property.
Our build system also specifies the property only while running the build
on the top of JDK 1.7.
If you want to help us and contribute in Maven project, you can open Pull
Requests in GitHub and update README.txt or README.md.
This would be helpful for all users and devs. Thx.
Of course you can better document the CLI with all these specifics. Ping us
on the mailing list when you are done!
Our projects in GitHub are typically named:
apache/maven
apache/maven-release
apache/maven-surefire
etc.
See all "Apache Maven" projects https://gitbox.apache.org/repos/asf/ or
list of plugins https://maven.apache.org/plugins/
Cheers
Tibor
On Sun, Jul 14, 2019 at 9:46 PM Clemens Quoss <clem...@quoss.de> wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
