I think a good compromise would be to introduce default value "TLS1.2" for
"https.protocols" in the POM section "properties" which can be overridden
in command line.
<properties>
<https.protocols>TLS1.2</https.protocols>
</properties>
On Wed, Jul 24, 2019 at 11:37 PM 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]
>
>
