Re: ITs in maven-release

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

Re: ITs in maven-release

Clemens Quoss
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 <[hidden email]> 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 <[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

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 <[hidden email]> 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 <[hidden email]> 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 <[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]
>
>