Re: ITs in maven-release

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

Re: ITs in maven-release

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]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: ITs in maven-release

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]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: ITs in maven-release

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

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