Re: ITs in maven-release

2019-07-14 Thread 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  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  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 
> 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 

Re: Naming of ITs in maven-release

2019-07-14 Thread Olivier Lamy
Hi
I agree the name is a bit confusing...
maybe name the IT: MRELEASE-229-RemoveScmTagPhase?


On Sun, 14 Jul 2019 at 20:06, Clemens Quoss  wrote:

> Hello everyone,
>
> one more question regarding the name of the ITs in maven-release (or
> maybe generally):
>
> Seeing that the tests are named after the jira issues i am wondering if
> that would be the right thing to do.
>
> Shouldn't they be named after the functionality they are testing?
>
> I for my part, being new to the whole thing, have provided a PR for
> MRELEASE-229 (implementing RemoveScmTagPhase with some unit tests) [1].
>
> Now i would like to see if there are IT for ScmTagPhase to help me in my
> orientation.
>
> For goal prepare there seem to exist the following:
>
> ...
>
> 10.07.2019  08:16  completion-goals
> 17.02.2019  23:40  flat-multi-module
> 10.07.2019  08:16  forked-basic
> 10.07.2019  08:16  invoker-basic
> 10.07.2019  08:16   833 invoker.properties
> 10.07.2019  08:15  MRELEASE-128
> 10.07.2019  08:15  MRELEASE-156
> 10.07.2019  08:15  MRELEASE-161
> 10.07.2019  08:15 MRELEASE-161-dependencyManagement
> 10.07.2019  08:15  MRELEASE-420
> 10.07.2019  08:15  MRELEASE-483
> 10.07.2019  08:15  MRELEASE-533
> 10.07.2019  08:15  MRELEASE-571_M3
> 10.07.2019  08:16  MRELEASE-618
> 10.07.2019  08:16  MRELEASE-667
> 17.02.2019  23:40  MRELEASE-834
> 10.07.2019  08:16  MRELEASE-966
> 10.07.2019  08:16  MRELEASE-976
> 10.07.2019  08:16  regular-multi-module
>
> ...
>
> Maybe one of the MRELEASE-... ITs does something with ScmTagPhase, maybe
> not.  I will have to look into everyone of them to decide.
>
> Would there be a test or tests named 'scm-tag-phase' or
> 'scm-tag-phase-MRELEASE-...' this would be of help, at least to me.
>
> Or have I misunderstood some fundamental concept here?
>
> Regards,
>
> Clemens
>
> [1] https://github.com/apache/maven-release/pull/29
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy


Re: ITs in maven-release

2019-07-14 Thread 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  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  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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: ITs in maven-release

2019-07-14 Thread 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  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  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-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


Re: ITs in maven-release

2019-07-14 Thread Clemens Quoss

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  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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: ITs in maven-release

2019-07-14 Thread 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  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-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


Re: ITs in maven-release

2019-07-14 Thread Enrico Olivelli
Il dom 14 lug 2019, 11:52 Clemens Quoss  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-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


Naming of ITs in maven-release

2019-07-14 Thread Clemens Quoss

Hello everyone,

one more question regarding the name of the ITs in maven-release (or 
maybe generally):


Seeing that the tests are named after the jira issues i am wondering if 
that would be the right thing to do.


Shouldn't they be named after the functionality they are testing?

I for my part, being new to the whole thing, have provided a PR for 
MRELEASE-229 (implementing RemoveScmTagPhase with some unit tests) [1].


Now i would like to see if there are IT for ScmTagPhase to help me in my 
orientation.


For goal prepare there seem to exist the following:

...

10.07.2019  08:16      completion-goals
17.02.2019  23:40      flat-multi-module
10.07.2019  08:16      forked-basic
10.07.2019  08:16      invoker-basic
10.07.2019  08:16   833 invoker.properties
10.07.2019  08:15      MRELEASE-128
10.07.2019  08:15      MRELEASE-156
10.07.2019  08:15      MRELEASE-161
10.07.2019  08:15     MRELEASE-161-dependencyManagement
10.07.2019  08:15      MRELEASE-420
10.07.2019  08:15      MRELEASE-483
10.07.2019  08:15      MRELEASE-533
10.07.2019  08:15      MRELEASE-571_M3
10.07.2019  08:16      MRELEASE-618
10.07.2019  08:16      MRELEASE-667
17.02.2019  23:40      MRELEASE-834
10.07.2019  08:16      MRELEASE-966
10.07.2019  08:16      MRELEASE-976
10.07.2019  08:16      regular-multi-module

...

Maybe one of the MRELEASE-... ITs does something with ScmTagPhase, maybe 
not.  I will have to look into everyone of them to decide.


Would there be a test or tests named 'scm-tag-phase' or 
'scm-tag-phase-MRELEASE-...' this would be of help, at least to me.


Or have I misunderstood some fundamental concept here?

Regards,

Clemens

[1] https://github.com/apache/maven-release/pull/29


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



ITs in maven-release

2019-07-14 Thread Clemens Quoss

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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org