You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Clemens Quoss <cl...@quoss.de> on 2019/07/14 09:52:15 UTC
ITs in maven-release
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: ITs in maven-release
Posted by Clemens Quoss <cl...@quoss.de>.
Hi Tibor,
as I already stated I was completely unaware of this whole
TLS-not-being-supported-below-1.2 anymore issue.
And i just tried and build maven-release successfully with JDK 7 Update
80, but using the UK mirror eplicitly in my settings.
I just tried it on my laptop with maven 3.6.1 and JDK 7 Update 80 and
not using the UK mirror and i get, as expected:
Caused by: javax.net.ssl.SSLException: Received fatal alert:
protocol_version
OK, then I provided -Dhttps.protocols=TLSv1.2 and it worked. Still, for
the plugin i suggest to change lines 265/266 of POM to
<https.protocols>TLSv1.2</https.protocols>
<arguments>-Dhttps.protocols=TLSv1.2</arguments>
since no other TLS version makes sense here, IMHO. Then there would be
no need to provide a property when running the release plugin with JDK 7.
Cheers, Clemens
Am 24.07.2019 um 19:00 schrieb Tibor Digana:
> Hi Clemens,
>
> Does JDK 7u80 work for you on fresh empty local repo?
>
> It does not for me on Surefire project! The Maven fails downloading the
> artifacts from Maven Central this month. Before the build was okay.
>
> So I issued the ticket https://issues.apache.org/jira/browse/INFRA-18775
> and I hope that our INFRA team will accept Zulu JDK from Azul Systems. The
> Zulu JDK is being maintained quite long. Of course the best decision would
> be to have extended support from the Oracle and use latest JDK but I am
> sceptical about it due to the Oracle's LTS is not free.
>
> Cheers
> Tibor
>
>
>
> On Tue, Jul 23, 2019 at 7:34 PM Robert Scholte <rf...@apache.org> wrote:
>
>> 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 <cl...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: ITs in maven-release
Posted by Tibor Digana <ti...@apache.org>.
Hi Clemens,
Does JDK 7u80 work for you on fresh empty local repo?
It does not for me on Surefire project! The Maven fails downloading the
artifacts from Maven Central this month. Before the build was okay.
So I issued the ticket https://issues.apache.org/jira/browse/INFRA-18775
and I hope that our INFRA team will accept Zulu JDK from Azul Systems. The
Zulu JDK is being maintained quite long. Of course the best decision would
be to have extended support from the Oracle and use latest JDK but I am
sceptical about it due to the Oracle's LTS is not free.
Cheers
Tibor
On Tue, Jul 23, 2019 at 7:34 PM Robert Scholte <rf...@apache.org> wrote:
> 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 <cl...@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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: ITs in maven-release
Posted by Tibor Digana <ti...@apache.org>.
typo: TLSv1.2
On Thu, Jul 25, 2019 at 12:14 AM Tibor Digana <ti...@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 <cl...@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 <cl...@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 <cl...@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-unsubscribe@maven.apache.org
>> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
Re: ITs in maven-release
Posted by Tibor Digana <ti...@apache.org>.
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 <cl...@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 <cl...@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 <cl...@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-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: ITs in maven-release
Posted by Tibor Digana <ti...@apache.org>.
Hi Robert,
I was investigating this issue long. The problem was with IDEA. Yesterday I
installed new version 2019.2 and set JDK 1.7 as system JAVA_HOME but the
project used JDK 1.8, see [1].
Suddenly, the maven-invoker-plugin used JAVA_HOME from the system and not
from IDEA settings. It wasn't problem of invoker but IDEA which used system
Java. I don't have explanation why it is so however Maven prented right
Java [1].
After I used native commandline, the build has passed successfully.
To confirm this, I used build-helper-maven-plugin, wrote BeanShell script,
printed JAVA_HOME in the integration test "build-archetype".
Altogether, our Jenkins is okay on apache/maven-resolver. The only problem
was with my development tool!
No worries in this case!
[1]:
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
2019-04-04T21:00:29+02:00)
Maven home: C:\Program Files\JetBrains\IntelliJ IDEA Community Edition
2019.2\plugins\maven\lib\maven3
Java version: 1.8.0_212, vendor: Oracle Corporation, runtime: C:\Program
Files\Java\jdk1.8.0_212\jre
On Fri, Jul 26, 2019 at 8:55 PM Robert Scholte <rf...@apache.org> wrote:
> Hi Tibor,
>
> off topic, but step 3 should of course be verify...
>
> I can't reproduce it, nor can Jenkins@ASF, see
> https://builds.apache.org/job/maven-box/job/maven-resolver/job/master/
>
> Based on the exception I would expect that the runtime is Java 7, not
> Java
> 8.
> Please verify the complete logfile, ensure it starts with mvn -V to see
> the version output.
>
> thanks,
> Robert
>
>
> On Fri, 26 Jul 2019 16:41:58 +0200, Tibor Digana <ti...@apache.org>
>
> wrote:
>
> > Hi Robert,
> >
> > I have very similar issue in apache/maven-resolver on my PC.
> > I don't know if the root cause is identical with the one you described in
> > your email regarding the parameter mavenOpts and shared environment
> > variable but I am sure you can reproduce it too.
> > These are my reprosteps:
> >
> > 1. clone the project apache/maven-resolver
> > 2. use JDK 1.8 in JAVA_HOME
> > 3. run the build "mvn install -P run-its"
> >
> > The build fails with:
> >
> > [ERROR] The following builds failed:
> > The following builds failed:
> > * build-and-run-its\pom.xml
> > * build-archetype\pom.xml
> > * build-ignore-eol\pom.xml
> >
> > When you open
> > maven-archetype-plugin/target/it/projects/build-and-run-its/build.log you
> > will have the error which is typical for JDK7. The issue is that I
> > executed
> > the build with JDK8.
> > "Received fatal alert: protocol_version".
> >
> > Here is my console output:
> >
> > [INFO] [INFO] --------------------------------[ jar
> > ]---------------------------------
> > [INFO] [INFO] Downloading from local.central:
> >
> file:///C:/vcs/github/maven-archetype/maven-archetype-plugin/target/local-repo/org/apache/maven/plugins/maven-resources-plugin/2.6/maven-resources-plugin-2.6.pom
> > [INFO] [INFO] Downloading from central:
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-resources-plugin/2.6/maven-resources-plugin-2.6.pom
> > [INFO] [INFO]
> > ------------------------------------------------------------------------
> > [INFO] [INFO] BUILD FAILURE
> > [INFO] [INFO]
> > ------------------------------------------------------------------------
> > [INFO] [INFO] Total time: 1.286 s
> > [INFO] [INFO] Finished at: 2019-07-26T14:15:54+02:00
> > [INFO] [INFO]
> > ------------------------------------------------------------------------
> > [INFO] [ERROR] Plugin
> > org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its
> > dependencies could not be resolved: Failed to read artifact descriptor
> > for org.apache.maven.plugins:maven-resources-plugin:jar:2.6: Could not
> > transfer artifact
> > org.apache.maven.plugins:maven-resources-plugin:pom:2.6 from/to
> > central (https://repo.maven.apache.org/maven2): Received fatal alert:
> > protocol_version -> [Help 1]
> > [INFO] org.apache.maven.plugin.PluginResolutionException: Plugin
> > org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its
> > dependencies could not be resolved: Failed to read artifact descriptor
> > for org.apache.maven.plugins:maven-resources-plugin:jar:2.6
> > [INFO] at
> >
> org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve
> > (DefaultPluginDependenciesResolver.java:117)
> > [INFO] at
> >
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor
> > (DefaultMavenPluginManager.java:182)
> >
> >
> >
> >
> >
> >
> > On Fri, Jul 26, 2019 at 1:23 PM Robert Scholte <rf...@apache.org>
> > wrote:
> >
> >> 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
> >> <ti...@apache.org>
> >>
> >> 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 <rf...@apache.org>
> >> > 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 <cl...@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
> >> <cl...@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 <cl...@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-unsubscribe@maven.apache.org
> >> >> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >> >>>>>
> >> >> ---------------------------------------------------------------------
> >> >> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >> >>>>>
> >> >> >>>>
> >> >> ---------------------------------------------------------------------
> >> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >> >>>>
> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >> >>
> >> >> >
> >> >> >
> >> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: ITs in maven-release
Posted by Robert Scholte <rf...@apache.org>.
Hi Tibor,
off topic, but step 3 should of course be verify...
I can't reproduce it, nor can Jenkins@ASF, see
https://builds.apache.org/job/maven-box/job/maven-resolver/job/master/
Based on the exception I would expect that the runtime is Java 7, not Java
8.
Please verify the complete logfile, ensure it starts with mvn -V to see
the version output.
thanks,
Robert
On Fri, 26 Jul 2019 16:41:58 +0200, Tibor Digana <ti...@apache.org>
wrote:
> Hi Robert,
>
> I have very similar issue in apache/maven-resolver on my PC.
> I don't know if the root cause is identical with the one you described in
> your email regarding the parameter mavenOpts and shared environment
> variable but I am sure you can reproduce it too.
> These are my reprosteps:
>
> 1. clone the project apache/maven-resolver
> 2. use JDK 1.8 in JAVA_HOME
> 3. run the build "mvn install -P run-its"
>
> The build fails with:
>
> [ERROR] The following builds failed:
> The following builds failed:
> * build-and-run-its\pom.xml
> * build-archetype\pom.xml
> * build-ignore-eol\pom.xml
>
> When you open
> maven-archetype-plugin/target/it/projects/build-and-run-its/build.log you
> will have the error which is typical for JDK7. The issue is that I
> executed
> the build with JDK8.
> "Received fatal alert: protocol_version".
>
> Here is my console output:
>
> [INFO] [INFO] --------------------------------[ jar
> ]---------------------------------
> [INFO] [INFO] Downloading from local.central:
> file:///C:/vcs/github/maven-archetype/maven-archetype-plugin/target/local-repo/org/apache/maven/plugins/maven-resources-plugin/2.6/maven-resources-plugin-2.6.pom
> [INFO] [INFO] Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-resources-plugin/2.6/maven-resources-plugin-2.6.pom
> [INFO] [INFO]
> ------------------------------------------------------------------------
> [INFO] [INFO] BUILD FAILURE
> [INFO] [INFO]
> ------------------------------------------------------------------------
> [INFO] [INFO] Total time: 1.286 s
> [INFO] [INFO] Finished at: 2019-07-26T14:15:54+02:00
> [INFO] [INFO]
> ------------------------------------------------------------------------
> [INFO] [ERROR] Plugin
> org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its
> dependencies could not be resolved: Failed to read artifact descriptor
> for org.apache.maven.plugins:maven-resources-plugin:jar:2.6: Could not
> transfer artifact
> org.apache.maven.plugins:maven-resources-plugin:pom:2.6 from/to
> central (https://repo.maven.apache.org/maven2): Received fatal alert:
> protocol_version -> [Help 1]
> [INFO] org.apache.maven.plugin.PluginResolutionException: Plugin
> org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its
> dependencies could not be resolved: Failed to read artifact descriptor
> for org.apache.maven.plugins:maven-resources-plugin:jar:2.6
> [INFO] at
> org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve
> (DefaultPluginDependenciesResolver.java:117)
> [INFO] at
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor
> (DefaultMavenPluginManager.java:182)
>
>
>
>
>
>
> On Fri, Jul 26, 2019 at 1:23 PM Robert Scholte <rf...@apache.org>
> wrote:
>
>> 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
>> <ti...@apache.org>
>>
>> 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 <rf...@apache.org>
>> > 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 <cl...@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
>> <cl...@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 <cl...@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-unsubscribe@maven.apache.org
>> >> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >> >>>>>
>> >> ---------------------------------------------------------------------
>> >> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >> >>>>>
>> >> >>>>
>> >> ---------------------------------------------------------------------
>> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >> >>>>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >> >>
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: ITs in maven-release
Posted by Tibor Digana <ti...@apache.org>.
Hi Robert,
I have very similar issue in apache/maven-resolver on my PC.
I don't know if the root cause is identical with the one you described in
your email regarding the parameter mavenOpts and shared environment
variable but I am sure you can reproduce it too.
These are my reprosteps:
1. clone the project apache/maven-resolver
2. use JDK 1.8 in JAVA_HOME
3. run the build "mvn install -P run-its"
The build fails with:
[ERROR] The following builds failed:
The following builds failed:
* build-and-run-its\pom.xml
* build-archetype\pom.xml
* build-ignore-eol\pom.xml
When you open
maven-archetype-plugin/target/it/projects/build-and-run-its/build.log you
will have the error which is typical for JDK7. The issue is that I executed
the build with JDK8.
"Received fatal alert: protocol_version".
Here is my console output:
[INFO] [INFO] --------------------------------[ jar
]---------------------------------
[INFO] [INFO] Downloading from local.central:
file:///C:/vcs/github/maven-archetype/maven-archetype-plugin/target/local-repo/org/apache/maven/plugins/maven-resources-plugin/2.6/maven-resources-plugin-2.6.pom
[INFO] [INFO] Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-resources-plugin/2.6/maven-resources-plugin-2.6.pom
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] BUILD FAILURE
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Total time: 1.286 s
[INFO] [INFO] Finished at: 2019-07-26T14:15:54+02:00
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [ERROR] Plugin
org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its
dependencies could not be resolved: Failed to read artifact descriptor
for org.apache.maven.plugins:maven-resources-plugin:jar:2.6: Could not
transfer artifact
org.apache.maven.plugins:maven-resources-plugin:pom:2.6 from/to
central (https://repo.maven.apache.org/maven2): Received fatal alert:
protocol_version -> [Help 1]
[INFO] org.apache.maven.plugin.PluginResolutionException: Plugin
org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its
dependencies could not be resolved: Failed to read artifact descriptor
for org.apache.maven.plugins:maven-resources-plugin:jar:2.6
[INFO] at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve
(DefaultPluginDependenciesResolver.java:117)
[INFO] at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor
(DefaultMavenPluginManager.java:182)
On Fri, Jul 26, 2019 at 1:23 PM Robert Scholte <rf...@apache.org> wrote:
> 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 <ti...@apache.org>
>
> 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 <rf...@apache.org>
> > 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 <cl...@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 <cl...@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 <cl...@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-unsubscribe@maven.apache.org
> >> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>>>>
> >> ---------------------------------------------------------------------
> >> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>>>>
> >> >>>>
> >> ---------------------------------------------------------------------
> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>>>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: ITs in maven-release
Posted by Robert Scholte <rf...@apache.org>.
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 <ti...@apache.org>
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 <rf...@apache.org>
> 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 <cl...@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 <cl...@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 <cl...@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-unsubscribe@maven.apache.org
>> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>>>>
>> ---------------------------------------------------------------------
>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>>>>
>> >>>>
>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: ITs in maven-release
Posted by Tibor Digana <ti...@apache.org>.
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 <rf...@apache.org> 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 <cl...@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 <cl...@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 <cl...@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-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: ITs in maven-release
Posted by Robert Scholte <rf...@apache.org>.
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 <cl...@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 <cl...@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 <cl...@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: ITs in maven-release
Posted by Clemens Quoss <cl...@quoss.de>.
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 <cl...@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 <cl...@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: ITs in maven-release
Posted by Robert Scholte <rf...@apache.org>.
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 <cl...@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 <cl...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: ITs in maven-release
Posted by Clemens Quoss <cl...@quoss.de>.
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 <cl...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: ITs in maven-release
Posted by Robert Scholte <rf...@apache.org>.
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 <cl...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: ITs in maven-release
Posted by Clemens Quoss <cl...@quoss.de>.
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 <cl...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: ITs in maven-release
Posted by Robert Scholte <rf...@apache.org>.
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 <cl...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: ITs in maven-release
Posted by Enrico Olivelli <eo...@gmail.com>.
Il dom 14 lug 2019, 11:52 Clemens Quoss <cl...@quoss.de> ha scritto:
> 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?
Yes
Enrico
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: ITs in maven-release
Posted by Clemens Quoss <cl...@quoss.de>.
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 <cl...@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 <cl...@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 <cl...@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: ITs in maven-release
Posted by Tibor Digana <ti...@apache.org>.
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 <cl...@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 <cl...@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 <cl...@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-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: ITs in maven-release
Posted by Clemens Quoss <cl...@quoss.de>.
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 <cl...@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 <cl...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: ITs in maven-release
Posted by Tibor Digana <ti...@apache.org>.
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 <cl...@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 <cl...@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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: ITs in maven-release
Posted by Clemens Quoss <cl...@quoss.de>.
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 <cl...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: ITs in maven-release
Posted by Tibor Digana <ti...@apache.org>.
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 <cl...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>