Re: ITs in maven-release

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

Re: ITs in maven-release

Clemens Quoss
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]

Reply | Threaded
Open this post in threaded view
|

Re: ITs in maven-release

Tibor Digana
typo: TLSv1.2

On Thu, Jul 25, 2019 at 12:14 AM Tibor Digana <[hidden email]>
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 <[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]
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: ITs in maven-release

Tibor Digana
In reply to this post by Clemens Quoss
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 <[hidden email]> 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 <[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]
>
> ---------------------------------------------------------------------
> 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
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 <[hidden email]>  
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 <[hidden email]>  
> 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 <[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]
>>
>> ---------------------------------------------------------------------
>> 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]