Looks like the same issue as there was with the maven site plugin: the
failing it was using mavenOpts as well.
I'm pretty sure that mavenOpts is not isolated and can be changed by any
other process on the same server.
Instead one should be using test.properties to pass those properties,
which are isolated.
Robert
On Thu, 25 Jul 2019 14:20:53 +0200, Tibor Digana
<[email protected]>
wrote:
> 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]
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
