typo: TLSv1.2
On Thu, Jul 25, 2019 at 12:14 AM Tibor Digana <tibordig...@apache.org>
wrote:
> 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 <clem...@quoss.de> 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 <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
>>
>>
