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 <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
> >> 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 <[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]
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >> 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]
>
>
