Re: ITs in maven-release

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: ITs in maven-release

rfscholte
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ITs in maven-release

Clemens Quoss
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 <[hidden email]>
> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ITs in maven-release

rfscholte
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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ITs in maven-release

rfscholte
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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ITs in maven-release

Clemens Quoss
In reply to this post by rfscholte
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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ITs in maven-release

Tibor Digana
In reply to this post by rfscholte
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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]> 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: [hidden email]
> >>>>> For additional commands, e-mail: [hidden email]
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: [hidden email]
> >>>> For additional commands, e-mail: [hidden email]
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>