Re: Surefire maintenance release

[Benedikt Ritter]

Am Do., 25. Apr. 2019 um 22:08 Uhr schrieb Enrico Olivelli <
eolive...@gmail.com>:

> FYI
> I have staged the release artifacts at
> https://repository.apache.org/content/repositories/maven-1500/
> and created the tag
>
> but I have to do some burocratic steps in JIRA before sending the
> official [VOTE] email
> I have sent other emails on this mailing list in order to complete my task
>
> @Stephane Nicoll if you want to try out the artifacts you are welcome.
> Anyway I will expect an official +1 on the VOTE thread
>
> I am sorry that the procedure takes so long but the staging proceure
> (mvn release:prepare...release:perform) must run all of the Its and it
> longs 2h
>

Helllo Enrico,

the staged artifacts passed our internal test suite.

Regards,
Benedikt


>
> Enrico
>
> Il giorno gio 25 apr 2019 alle ore 10:25 Enrico Olivelli
>  ha scritto:
> >
> > Staging the artifact now.
> > It will take the whole day I guess
> >
> > Enrico
> >
> > Il mer 24 apr 2019, 13:21 Enrico Olivelli  ha
> scritto:
> >>
> >> Il giorno mer 24 apr 2019 alle ore 12:30 Tibor Digana
> >>  ha scritto:
> >> >
> >> > What a test has failed?
> >> > In this CI job all tests have passed successfully and the job is
> "blue".
> >>
> >> You are right !
> >> My browser should have get messed somehow
> >>
> >> So we are good to go
> >> sorry for beeing so late
> >>
> >> Enrico
> >>
> >> >
> >> > On Wed, Apr 24, 2019 at 8:28 AM Enrico Olivelli 
> wrote:
> >> >
> >> > > I am sorry,
> >> > > I had other priorities, this task is not still complete.
> >> > >
> >> > > Tests are still failing and this is weird because I think I saw
> them green.
> >> > >
> >> > > This is the link to the job
> >> > >
> >> > >
> >> > >
> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-surefire/job/release%252F2.22.2/
> >> > >
> >> > > Enrico
> >> > >
> >> > > Il gio 11 apr 2019, 08:11 Christian Stein  ha
> scritto:
> >> > >
> >> > > > On Thu, Apr 11, 2019 at 8:09 AM Enrico Olivelli <
> eolive...@gmail.com>
> >> > > > wrote:
> >> > > >
> >> > > > > This is the final branch from which I will cut the release.
> >> > > > > https://github.com/apache/maven-surefire/tree/release/2.22.2
> >> > > > >
> >> > > > > Re-launched Jenkins to check for the last time:
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> https://builds.apache.org/job/maven-box/job/maven-surefire/job/release%252F2.22.2/
> >> > > > >
> >> > > > >
> >> > > > Go, Jenkins, go! ;-)
> >> > > >
> >> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Surefire maintenance release

[Enrico Olivelli]

Il giorno ven 26 apr 2019 alle ore 15:59 Stephane Nicoll
 ha scritto:
>
> Awesome, thanks a lot Enrico. Will give the staging release a try next week.

Okay,
Anyway I will start the official [VOTE] thread soon, today or tomorrow.

Cheers

Enrico


>
> Cheers,
> S.
>
> On Thu, Apr 25, 2019 at 11:08 PM Enrico Olivelli 
> wrote:
>
> > FYI
> > I have staged the release artifacts at
> > https://repository.apache.org/content/repositories/maven-1500/
> > and created the tag
> >
> > but I have to do some burocratic steps in JIRA before sending the
> > official [VOTE] email
> > I have sent other emails on this mailing list in order to complete my task
> >
> > @Stephane Nicoll if you want to try out the artifacts you are welcome.
> > Anyway I will expect an official +1 on the VOTE thread
> >
> > I am sorry that the procedure takes so long but the staging proceure
> > (mvn release:prepare...release:perform) must run all of the Its and it
> > longs 2h
> >
> > Enrico
> >
> > Il giorno gio 25 apr 2019 alle ore 10:25 Enrico Olivelli
> >  ha scritto:
> > >
> > > Staging the artifact now.
> > > It will take the whole day I guess
> > >
> > > Enrico
> > >
> > > Il mer 24 apr 2019, 13:21 Enrico Olivelli  ha
> > scritto:
> > >>
> > >> Il giorno mer 24 apr 2019 alle ore 12:30 Tibor Digana
> > >>  ha scritto:
> > >> >
> > >> > What a test has failed?
> > >> > In this CI job all tests have passed successfully and the job is
> > "blue".
> > >>
> > >> You are right !
> > >> My browser should have get messed somehow
> > >>
> > >> So we are good to go
> > >> sorry for beeing so late
> > >>
> > >> Enrico
> > >>
> > >> >
> > >> > On Wed, Apr 24, 2019 at 8:28 AM Enrico Olivelli 
> > wrote:
> > >> >
> > >> > > I am sorry,
> > >> > > I had other priorities, this task is not still complete.
> > >> > >
> > >> > > Tests are still failing and this is weird because I think I saw
> > them green.
> > >> > >
> > >> > > This is the link to the job
> > >> > >
> > >> > >
> > >> > >
> > https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-surefire/job/release%252F2.22.2/
> > >> > >
> > >> > > Enrico
> > >> > >
> > >> > > Il gio 11 apr 2019, 08:11 Christian Stein  ha
> > scritto:
> > >> > >
> > >> > > > On Thu, Apr 11, 2019 at 8:09 AM Enrico Olivelli <
> > eolive...@gmail.com>
> > >> > > > wrote:
> > >> > > >
> > >> > > > > This is the final branch from which I will cut the release.
> > >> > > > > https://github.com/apache/maven-surefire/tree/release/2.22.2
> > >> > > > >
> > >> > > > > Re-launched Jenkins to check for the last time:
> > >> > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > https://builds.apache.org/job/maven-box/job/maven-surefire/job/release%252F2.22.2/
> > >> > > > >
> > >> > > > >
> > >> > > > Go, Jenkins, go! ;-)
> > >> > > >
> > >> > >
> >

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

Re: Surefire maintenance release

[Stephane Nicoll]

Awesome, thanks a lot Enrico. Will give the staging release a try next week.

Cheers,
S.

On Thu, Apr 25, 2019 at 11:08 PM Enrico Olivelli 
wrote:

> FYI
> I have staged the release artifacts at
> https://repository.apache.org/content/repositories/maven-1500/
> and created the tag
>
> but I have to do some burocratic steps in JIRA before sending the
> official [VOTE] email
> I have sent other emails on this mailing list in order to complete my task
>
> @Stephane Nicoll if you want to try out the artifacts you are welcome.
> Anyway I will expect an official +1 on the VOTE thread
>
> I am sorry that the procedure takes so long but the staging proceure
> (mvn release:prepare...release:perform) must run all of the Its and it
> longs 2h
>
> Enrico
>
> Il giorno gio 25 apr 2019 alle ore 10:25 Enrico Olivelli
>  ha scritto:
> >
> > Staging the artifact now.
> > It will take the whole day I guess
> >
> > Enrico
> >
> > Il mer 24 apr 2019, 13:21 Enrico Olivelli  ha
> scritto:
> >>
> >> Il giorno mer 24 apr 2019 alle ore 12:30 Tibor Digana
> >>  ha scritto:
> >> >
> >> > What a test has failed?
> >> > In this CI job all tests have passed successfully and the job is
> "blue".
> >>
> >> You are right !
> >> My browser should have get messed somehow
> >>
> >> So we are good to go
> >> sorry for beeing so late
> >>
> >> Enrico
> >>
> >> >
> >> > On Wed, Apr 24, 2019 at 8:28 AM Enrico Olivelli 
> wrote:
> >> >
> >> > > I am sorry,
> >> > > I had other priorities, this task is not still complete.
> >> > >
> >> > > Tests are still failing and this is weird because I think I saw
> them green.
> >> > >
> >> > > This is the link to the job
> >> > >
> >> > >
> >> > >
> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-surefire/job/release%252F2.22.2/
> >> > >
> >> > > Enrico
> >> > >
> >> > > Il gio 11 apr 2019, 08:11 Christian Stein  ha
> scritto:
> >> > >
> >> > > > On Thu, Apr 11, 2019 at 8:09 AM Enrico Olivelli <
> eolive...@gmail.com>
> >> > > > wrote:
> >> > > >
> >> > > > > This is the final branch from which I will cut the release.
> >> > > > > https://github.com/apache/maven-surefire/tree/release/2.22.2
> >> > > > >
> >> > > > > Re-launched Jenkins to check for the last time:
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> https://builds.apache.org/job/maven-box/job/maven-surefire/job/release%252F2.22.2/
> >> > > > >
> >> > > > >
> >> > > > Go, Jenkins, go! ;-)
> >> > > >
> >> > >
>

Re: Surefire maintenance release

[Enrico Olivelli]

FYI
I have staged the release artifacts at
https://repository.apache.org/content/repositories/maven-1500/
and created the tag

but I have to do some burocratic steps in JIRA before sending the
official [VOTE] email
I have sent other emails on this mailing list in order to complete my task

@Stephane Nicoll if you want to try out the artifacts you are welcome.
Anyway I will expect an official +1 on the VOTE thread

I am sorry that the procedure takes so long but the staging proceure
(mvn release:prepare...release:perform) must run all of the Its and it
longs 2h

Enrico

Il giorno gio 25 apr 2019 alle ore 10:25 Enrico Olivelli
 ha scritto:
>
> Staging the artifact now.
> It will take the whole day I guess
>
> Enrico
>
> Il mer 24 apr 2019, 13:21 Enrico Olivelli  ha scritto:
>>
>> Il giorno mer 24 apr 2019 alle ore 12:30 Tibor Digana
>>  ha scritto:
>> >
>> > What a test has failed?
>> > In this CI job all tests have passed successfully and the job is "blue".
>>
>> You are right !
>> My browser should have get messed somehow
>>
>> So we are good to go
>> sorry for beeing so late
>>
>> Enrico
>>
>> >
>> > On Wed, Apr 24, 2019 at 8:28 AM Enrico Olivelli  
>> > wrote:
>> >
>> > > I am sorry,
>> > > I had other priorities, this task is not still complete.
>> > >
>> > > Tests are still failing and this is weird because I think I saw them 
>> > > green.
>> > >
>> > > This is the link to the job
>> > >
>> > >
>> > > https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-surefire/job/release%252F2.22.2/
>> > >
>> > > Enrico
>> > >
>> > > Il gio 11 apr 2019, 08:11 Christian Stein  ha 
>> > > scritto:
>> > >
>> > > > On Thu, Apr 11, 2019 at 8:09 AM Enrico Olivelli 
>> > > > wrote:
>> > > >
>> > > > > This is the final branch from which I will cut the release.
>> > > > > https://github.com/apache/maven-surefire/tree/release/2.22.2
>> > > > >
>> > > > > Re-launched Jenkins to check for the last time:
>> > > > >
>> > > > >
>> > > >
>> > > https://builds.apache.org/job/maven-box/job/maven-surefire/job/release%252F2.22.2/
>> > > > >
>> > > > >
>> > > > Go, Jenkins, go! ;-)
>> > > >
>> > >

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

Re: Surefire maintenance release

[Enrico Olivelli]

Staging the artifact now.
It will take the whole day I guess

Enrico

Il mer 24 apr 2019, 13:21 Enrico Olivelli  ha scritto:

> Il giorno mer 24 apr 2019 alle ore 12:30 Tibor Digana
>  ha scritto:
> >
> > What a test has failed?
> > In this CI job all tests have passed successfully and the job is "blue".
>
> You are right !
> My browser should have get messed somehow
>
> So we are good to go
> sorry for beeing so late
>
> Enrico
>
> >
> > On Wed, Apr 24, 2019 at 8:28 AM Enrico Olivelli 
> wrote:
> >
> > > I am sorry,
> > > I had other priorities, this task is not still complete.
> > >
> > > Tests are still failing and this is weird because I think I saw them
> green.
> > >
> > > This is the link to the job
> > >
> > >
> > >
> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-surefire/job/release%252F2.22.2/
> > >
> > > Enrico
> > >
> > > Il gio 11 apr 2019, 08:11 Christian Stein  ha
> scritto:
> > >
> > > > On Thu, Apr 11, 2019 at 8:09 AM Enrico Olivelli  >
> > > > wrote:
> > > >
> > > > > This is the final branch from which I will cut the release.
> > > > > https://github.com/apache/maven-surefire/tree/release/2.22.2
> > > > >
> > > > > Re-launched Jenkins to check for the last time:
> > > > >
> > > > >
> > > >
> > >
> https://builds.apache.org/job/maven-box/job/maven-surefire/job/release%252F2.22.2/
> > > > >
> > > > >
> > > > Go, Jenkins, go! ;-)
> > > >
> > >
>

Re: Surefire maintenance release

[Enrico Olivelli]

Il giorno mer 24 apr 2019 alle ore 12:30 Tibor Digana
 ha scritto:
>
> What a test has failed?
> In this CI job all tests have passed successfully and the job is "blue".

You are right !
My browser should have get messed somehow

So we are good to go
sorry for beeing so late

Enrico

>
> On Wed, Apr 24, 2019 at 8:28 AM Enrico Olivelli  wrote:
>
> > I am sorry,
> > I had other priorities, this task is not still complete.
> >
> > Tests are still failing and this is weird because I think I saw them green.
> >
> > This is the link to the job
> >
> >
> > https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-surefire/job/release%252F2.22.2/
> >
> > Enrico
> >
> > Il gio 11 apr 2019, 08:11 Christian Stein  ha scritto:
> >
> > > On Thu, Apr 11, 2019 at 8:09 AM Enrico Olivelli 
> > > wrote:
> > >
> > > > This is the final branch from which I will cut the release.
> > > > https://github.com/apache/maven-surefire/tree/release/2.22.2
> > > >
> > > > Re-launched Jenkins to check for the last time:
> > > >
> > > >
> > >
> > https://builds.apache.org/job/maven-box/job/maven-surefire/job/release%252F2.22.2/
> > > >
> > > >
> > > Go, Jenkins, go! ;-)
> > >
> >

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

Re: Surefire maintenance release

[Tibor Digana]

What a test has failed?
In this CI job all tests have passed successfully and the job is "blue".

On Wed, Apr 24, 2019 at 8:28 AM Enrico Olivelli  wrote:

> I am sorry,
> I had other priorities, this task is not still complete.
>
> Tests are still failing and this is weird because I think I saw them green.
>
> This is the link to the job
>
>
> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-surefire/job/release%252F2.22.2/
>
> Enrico
>
> Il gio 11 apr 2019, 08:11 Christian Stein  ha scritto:
>
> > On Thu, Apr 11, 2019 at 8:09 AM Enrico Olivelli 
> > wrote:
> >
> > > This is the final branch from which I will cut the release.
> > > https://github.com/apache/maven-surefire/tree/release/2.22.2
> > >
> > > Re-launched Jenkins to check for the last time:
> > >
> > >
> >
> https://builds.apache.org/job/maven-box/job/maven-surefire/job/release%252F2.22.2/
> > >
> > >
> > Go, Jenkins, go! ;-)
> >
>

Re: Surefire maintenance release

[Enrico Olivelli]

I am sorry,
I had other priorities, this task is not still complete.

Tests are still failing and this is weird because I think I saw them green.

This is the link to the job

https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-surefire/job/release%252F2.22.2/

Enrico

Il gio 11 apr 2019, 08:11 Christian Stein  ha scritto:

> On Thu, Apr 11, 2019 at 8:09 AM Enrico Olivelli 
> wrote:
>
> > This is the final branch from which I will cut the release.
> > https://github.com/apache/maven-surefire/tree/release/2.22.2
> >
> > Re-launched Jenkins to check for the last time:
> >
> >
> https://builds.apache.org/job/maven-box/job/maven-surefire/job/release%252F2.22.2/
> >
> >
> Go, Jenkins, go! ;-)
>

Re: Surefire maintenance release

[Christian Stein]

On Thu, Apr 11, 2019 at 8:09 AM Enrico Olivelli  wrote:

> This is the final branch from which I will cut the release.
> https://github.com/apache/maven-surefire/tree/release/2.22.2
>
> Re-launched Jenkins to check for the last time:
>
> https://builds.apache.org/job/maven-box/job/maven-surefire/job/release%252F2.22.2/
>
>
Go, Jenkins, go! ;-)

Re: Surefire maintenance release

[Enrico Olivelli]

This is the final branch from which I will cut the release.
https://github.com/apache/maven-surefire/tree/release/2.22.2

Re-launched Jenkins to check for the last time:
https://builds.apache.org/job/maven-box/job/maven-surefire/job/release%252F2.22.2/


Enrico

Il giorno mer 10 apr 2019 alle ore 14:23 Enrico Olivelli
 ha scritto:
>
> Sorry for the delay
>
> The work branch seems in good shape.
> Now it is only a matter or cutting the release
>
>
> Enrico
>
> Il lun 1 apr 2019, 16:09 Enrico Olivelli  ha scritto:
>>
>>
>>
>> Il sab 30 mar 2019, 14:16 Enrico Olivelli  ha scritto:
>>>
>>> I have created a PR for your work Stephane
>>> https://github.com/apache/maven-surefire/pull/225
>>>
>>> I will do my best
>>> I am still new to the release procedure, never cut a release for surefire 
>>> and we usually are only cutting releases from master.
>>
>>
>> We are experiencing integration tests failures I am checking with Chris.
>> Any help is appreciated
>>
>> Enrico
>>
>>
>>>
>>>
>>> Enrico
>>>
>>>
>>>
>>> Il gio 28 mar 2019, 00:34 Olivier Lamy  ha scritto:

 On Thu, 28 Mar 2019 at 03:14, Enrico Olivelli  wrote:

 > Il mer 27 mar 2019, 18:10 Tibor Digana  ha
 > scritto:
 >
 > > Enrico, what i maintenance release for you, 2.22.2-M1?
 > >
 >
 > 2.22.2 without suffix
 >

 +1
 @Tibor if you are too busy maybe Enrico can cut the release if he has time.


 >
 >
 > Enrico
 >
 > >
 > >
 > >
 > >
 > > On Wed, Mar 27, 2019 at 6:07 PM Enrico Olivelli 
 > > wrote:
 > >
 > > > Stephane
 > > > thank you so much.
 > > > I think we will be able to cut a maintenaince release soon with your
 > > > branch.
 > > >
 > > > Maybe you can join us in chat with https://s.apache.org/slack-invite
 > > > #maven  channel
 > > >
 > > >
 > > > Enrico
 > > >
 > > > Il giorno mer 27 mar 2019 alle ore 15:45 Tibor Digana
 > > >  ha scritto:
 > > > >
 > > > > Stephane, What exists in our agreement are two issues 
 > > > > (SUREFIRE-1546
 > > and
 > > > > SUREFIRE-1614), you will have them but no multiple releases (not
 > > > effective
 > > > > in the perspectives of out spare time).
 > > > > We need people like you who will support us in 3.0.0-M4. This is 
 > > > > the
 > > main
 > > > > goal.
 > > > > The issues SUREFIRE-1546 and SUREFIRE-1614 will be delivered to 
 > > > > you,
 > > but
 > > > no
 > > > > more and not less.
 > > > > The thing is how you will participate by your hands in Java code. 
 > > > > The
 > > > > result depends on you.
 > > > > But again, this what we solve here is not important for ASF. It is
 > > > > important for you and your agenda.
 > > > > For the project is important the deal we made several years ago, 
 > > > > when
 > > we
 > > > > planned to provide Extensions API for the Users. To get there we 
 > > > > need
 > > to
 > > > > unfortunately rework internal code in Surefire project which takes
 > > > really a
 > > > > lots of time and spends private energy, and thus 2.22.2 is less
 > > important
 > > > > from this perspective. We have to support long standing vision but
 > the
 > > > > version 2.22.2 is something short lasting which you and some Spring
 > > guys
 > > > > wanted due to they have a problem* with their own internal rules* 
 > > > > and
 > > > > technically Spring project can solve this problem with 3.0.0-M3.
 > > > Therefore
 > > > > we are wasting the time if we write the code for you. Therefore you
 > > > should
 > > > > provide pull request by yourself as this is OSS and we can make a
 > code
 > > > > review. But our effort would be really only short time relevant if 
 > > > > we
 > > > > dedicate too much time in 2.22.2 with these two Jira issues. We 
 > > > > have
 > > few
 > > > > active Java developers and "stealing" them for your activity means
 > that
 > > > we
 > > > > are not effective and slow. Therefore, Stephane pls prepare the
 > commits
 > > > on
 > > > > your responsibility on GitHub in your pull request and we can 
 > > > > invest
 > > the
 > > > > time to check it including the build check and cutting the release
 > > > version.
 > > > >
 > > > > T
 > > > >
 > > > >
 > > > >
 > > > > On Wed, Mar 27, 2019 at 8:11 AM Stephane Nicoll <
 > > > stephane.nic...@gmail.com>
 > > > > wrote:
 > > > >
 > > > > > On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana <
 > > tibordig...@apache.org>
 > > > > > wrote:
 > > > > >
 > > > > > > Stephane,
 > > > > > >
 > > > > > > >> I wanted to make sure that the JUnit5 story was functional
 > > > > > >
 > > > > > > I really don't like politics.
 > > > > 

Re: Surefire maintenance release

[Stephane Nicoll]

Awesome work, thank you very much Enrico!

On Wed, Apr 10, 2019 at 3:29 PM Enrico Olivelli  wrote:

> Sorry for the delay
>
> The work branch seems in good shape.
> Now it is only a matter or cutting the release
>
>
> Enrico
>
> Il lun 1 apr 2019, 16:09 Enrico Olivelli  ha scritto:
>
> >
> >
> > Il sab 30 mar 2019, 14:16 Enrico Olivelli  ha
> > scritto:
> >
> >> I have created a PR for your work Stephane
> >> https://github.com/apache/maven-surefire/pull/225
> >>
> >> I will do my best
> >> I am still new to the release procedure, never cut a release for
> surefire
> >> and we usually are only cutting releases from master.
> >>
> >
> > We are experiencing integration tests failures I am checking with Chris.
> > Any help is appreciated
> >
> > Enrico
> >
> >
> >
> >>
> >> Enrico
> >>
> >>
> >>
> >> Il gio 28 mar 2019, 00:34 Olivier Lamy  ha scritto:
> >>
> >>> On Thu, 28 Mar 2019 at 03:14, Enrico Olivelli 
> >>> wrote:
> >>>
> >>> > Il mer 27 mar 2019, 18:10 Tibor Digana  ha
> >>> > scritto:
> >>> >
> >>> > > Enrico, what i maintenance release for you, 2.22.2-M1?
> >>> > >
> >>> >
> >>> > 2.22.2 without suffix
> >>> >
> >>>
> >>> +1
> >>> @Tibor if you are too busy maybe Enrico can cut the release if he has
> >>> time.
> >>>
> >>>
> >>> >
> >>> >
> >>> > Enrico
> >>> >
> >>> > >
> >>> > >
> >>> > >
> >>> > >
> >>> > > On Wed, Mar 27, 2019 at 6:07 PM Enrico Olivelli <
> eolive...@gmail.com
> >>> >
> >>> > > wrote:
> >>> > >
> >>> > > > Stephane
> >>> > > > thank you so much.
> >>> > > > I think we will be able to cut a maintenaince release soon with
> >>> your
> >>> > > > branch.
> >>> > > >
> >>> > > > Maybe you can join us in chat with
> >>> https://s.apache.org/slack-invite
> >>> > > > #maven  channel
> >>> > > >
> >>> > > >
> >>> > > > Enrico
> >>> > > >
> >>> > > > Il giorno mer 27 mar 2019 alle ore 15:45 Tibor Digana
> >>> > > >  ha scritto:
> >>> > > > >
> >>> > > > > Stephane, What exists in our agreement are two issues
> >>> (SUREFIRE-1546
> >>> > > and
> >>> > > > > SUREFIRE-1614), you will have them but no multiple releases
> (not
> >>> > > > effective
> >>> > > > > in the perspectives of out spare time).
> >>> > > > > We need people like you who will support us in 3.0.0-M4. This
> is
> >>> the
> >>> > > main
> >>> > > > > goal.
> >>> > > > > The issues SUREFIRE-1546 and SUREFIRE-1614 will be delivered to
> >>> you,
> >>> > > but
> >>> > > > no
> >>> > > > > more and not less.
> >>> > > > > The thing is how you will participate by your hands in Java
> >>> code. The
> >>> > > > > result depends on you.
> >>> > > > > But again, this what we solve here is not important for ASF. It
> >>> is
> >>> > > > > important for you and your agenda.
> >>> > > > > For the project is important the deal we made several years
> ago,
> >>> when
> >>> > > we
> >>> > > > > planned to provide Extensions API for the Users. To get there
> we
> >>> need
> >>> > > to
> >>> > > > > unfortunately rework internal code in Surefire project which
> >>> takes
> >>> > > > really a
> >>> > > > > lots of time and spends private energy, and thus 2.22.2 is less
> >>> > > important
> >>> > > > > from this perspective. We have to support long standing vision
> >>> but
> >>> > the
> >>> > > > > version 2.22.2 is something short lasting which you and some
> >>> Spring
> >>> > > guys
> >>> > > > > wanted due to they have a problem* with their own internal
> >>> rules* and
> >>> > > > > technically Spring project can solve this problem with
> 3.0.0-M3.
> >>> > > > Therefore
> >>> > > > > we are wasting the time if we write the code for you. Therefore
> >>> you
> >>> > > > should
> >>> > > > > provide pull request by yourself as this is OSS and we can
> make a
> >>> > code
> >>> > > > > review. But our effort would be really only short time relevant
> >>> if we
> >>> > > > > dedicate too much time in 2.22.2 with these two Jira issues. We
> >>> have
> >>> > > few
> >>> > > > > active Java developers and "stealing" them for your activity
> >>> means
> >>> > that
> >>> > > > we
> >>> > > > > are not effective and slow. Therefore, Stephane pls prepare the
> >>> > commits
> >>> > > > on
> >>> > > > > your responsibility on GitHub in your pull request and we can
> >>> invest
> >>> > > the
> >>> > > > > time to check it including the build check and cutting the
> >>> release
> >>> > > > version.
> >>> > > > >
> >>> > > > > T
> >>> > > > >
> >>> > > > >
> >>> > > > >
> >>> > > > > On Wed, Mar 27, 2019 at 8:11 AM Stephane Nicoll <
> >>> > > > stephane.nic...@gmail.com>
> >>> > > > > wrote:
> >>> > > > >
> >>> > > > > > On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana <
> >>> > > tibordig...@apache.org>
> >>> > > > > > wrote:
> >>> > > > > >
> >>> > > > > > > Stephane,
> >>> > > > > > >
> >>> > > > > > > >> I wanted to make sure that the JUnit5 story was
> functional
> >>> > > > > > >
> >>> > > > > > > I really don't like politics.
> >>> > > > > >
> >>> > > > > >
> >>> > > > > > What's that supposed to mean? If 

Re: Surefire maintenance release

[Enrico Olivelli]

Sorry for the delay

The work branch seems in good shape.
Now it is only a matter or cutting the release


Enrico

Il lun 1 apr 2019, 16:09 Enrico Olivelli  ha scritto:

>
>
> Il sab 30 mar 2019, 14:16 Enrico Olivelli  ha
> scritto:
>
>> I have created a PR for your work Stephane
>> https://github.com/apache/maven-surefire/pull/225
>>
>> I will do my best
>> I am still new to the release procedure, never cut a release for surefire
>> and we usually are only cutting releases from master.
>>
>
> We are experiencing integration tests failures I am checking with Chris.
> Any help is appreciated
>
> Enrico
>
>
>
>>
>> Enrico
>>
>>
>>
>> Il gio 28 mar 2019, 00:34 Olivier Lamy  ha scritto:
>>
>>> On Thu, 28 Mar 2019 at 03:14, Enrico Olivelli 
>>> wrote:
>>>
>>> > Il mer 27 mar 2019, 18:10 Tibor Digana  ha
>>> > scritto:
>>> >
>>> > > Enrico, what i maintenance release for you, 2.22.2-M1?
>>> > >
>>> >
>>> > 2.22.2 without suffix
>>> >
>>>
>>> +1
>>> @Tibor if you are too busy maybe Enrico can cut the release if he has
>>> time.
>>>
>>>
>>> >
>>> >
>>> > Enrico
>>> >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > On Wed, Mar 27, 2019 at 6:07 PM Enrico Olivelli >> >
>>> > > wrote:
>>> > >
>>> > > > Stephane
>>> > > > thank you so much.
>>> > > > I think we will be able to cut a maintenaince release soon with
>>> your
>>> > > > branch.
>>> > > >
>>> > > > Maybe you can join us in chat with
>>> https://s.apache.org/slack-invite
>>> > > > #maven  channel
>>> > > >
>>> > > >
>>> > > > Enrico
>>> > > >
>>> > > > Il giorno mer 27 mar 2019 alle ore 15:45 Tibor Digana
>>> > > >  ha scritto:
>>> > > > >
>>> > > > > Stephane, What exists in our agreement are two issues
>>> (SUREFIRE-1546
>>> > > and
>>> > > > > SUREFIRE-1614), you will have them but no multiple releases (not
>>> > > > effective
>>> > > > > in the perspectives of out spare time).
>>> > > > > We need people like you who will support us in 3.0.0-M4. This is
>>> the
>>> > > main
>>> > > > > goal.
>>> > > > > The issues SUREFIRE-1546 and SUREFIRE-1614 will be delivered to
>>> you,
>>> > > but
>>> > > > no
>>> > > > > more and not less.
>>> > > > > The thing is how you will participate by your hands in Java
>>> code. The
>>> > > > > result depends on you.
>>> > > > > But again, this what we solve here is not important for ASF. It
>>> is
>>> > > > > important for you and your agenda.
>>> > > > > For the project is important the deal we made several years ago,
>>> when
>>> > > we
>>> > > > > planned to provide Extensions API for the Users. To get there we
>>> need
>>> > > to
>>> > > > > unfortunately rework internal code in Surefire project which
>>> takes
>>> > > > really a
>>> > > > > lots of time and spends private energy, and thus 2.22.2 is less
>>> > > important
>>> > > > > from this perspective. We have to support long standing vision
>>> but
>>> > the
>>> > > > > version 2.22.2 is something short lasting which you and some
>>> Spring
>>> > > guys
>>> > > > > wanted due to they have a problem* with their own internal
>>> rules* and
>>> > > > > technically Spring project can solve this problem with 3.0.0-M3.
>>> > > > Therefore
>>> > > > > we are wasting the time if we write the code for you. Therefore
>>> you
>>> > > > should
>>> > > > > provide pull request by yourself as this is OSS and we can make a
>>> > code
>>> > > > > review. But our effort would be really only short time relevant
>>> if we
>>> > > > > dedicate too much time in 2.22.2 with these two Jira issues. We
>>> have
>>> > > few
>>> > > > > active Java developers and "stealing" them for your activity
>>> means
>>> > that
>>> > > > we
>>> > > > > are not effective and slow. Therefore, Stephane pls prepare the
>>> > commits
>>> > > > on
>>> > > > > your responsibility on GitHub in your pull request and we can
>>> invest
>>> > > the
>>> > > > > time to check it including the build check and cutting the
>>> release
>>> > > > version.
>>> > > > >
>>> > > > > T
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > On Wed, Mar 27, 2019 at 8:11 AM Stephane Nicoll <
>>> > > > stephane.nic...@gmail.com>
>>> > > > > wrote:
>>> > > > >
>>> > > > > > On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana <
>>> > > tibordig...@apache.org>
>>> > > > > > wrote:
>>> > > > > >
>>> > > > > > > Stephane,
>>> > > > > > >
>>> > > > > > > >> I wanted to make sure that the JUnit5 story was functional
>>> > > > > > >
>>> > > > > > > I really don't like politics.
>>> > > > > >
>>> > > > > >
>>> > > > > > What's that supposed to mean? If you want to quote something,
>>> > please
>>> > > > quote
>>> > > > > > the full sentence. The full sentence is *"I wanted to make sure
>>> > that
>>> > > > the
>>> > > > > > JUnit5 story was functional with the vintage engine and the
>>> current
>>> > > GA
>>> > > > of
>>> > > > > > surefire." *which I believe is an accurate description of the
>>> > current
>>> > > > > > situation.
>>> > > > > >
>>> > > > > >
>>> > > > > > > Did you see SUREFIRE-1614?
>>> > > > > >
>>> 

Re: Surefire maintenance release

[Enrico Olivelli]

Il sab 30 mar 2019, 14:16 Enrico Olivelli  ha scritto:

> I have created a PR for your work Stephane
> https://github.com/apache/maven-surefire/pull/225
>
> I will do my best
> I am still new to the release procedure, never cut a release for surefire
> and we usually are only cutting releases from master.
>

We are experiencing integration tests failures I am checking with Chris.
Any help is appreciated

Enrico



>
> Enrico
>
>
>
> Il gio 28 mar 2019, 00:34 Olivier Lamy  ha scritto:
>
>> On Thu, 28 Mar 2019 at 03:14, Enrico Olivelli 
>> wrote:
>>
>> > Il mer 27 mar 2019, 18:10 Tibor Digana  ha
>> > scritto:
>> >
>> > > Enrico, what i maintenance release for you, 2.22.2-M1?
>> > >
>> >
>> > 2.22.2 without suffix
>> >
>>
>> +1
>> @Tibor if you are too busy maybe Enrico can cut the release if he has
>> time.
>>
>>
>> >
>> >
>> > Enrico
>> >
>> > >
>> > >
>> > >
>> > >
>> > > On Wed, Mar 27, 2019 at 6:07 PM Enrico Olivelli 
>> > > wrote:
>> > >
>> > > > Stephane
>> > > > thank you so much.
>> > > > I think we will be able to cut a maintenaince release soon with your
>> > > > branch.
>> > > >
>> > > > Maybe you can join us in chat with
>> https://s.apache.org/slack-invite
>> > > > #maven  channel
>> > > >
>> > > >
>> > > > Enrico
>> > > >
>> > > > Il giorno mer 27 mar 2019 alle ore 15:45 Tibor Digana
>> > > >  ha scritto:
>> > > > >
>> > > > > Stephane, What exists in our agreement are two issues
>> (SUREFIRE-1546
>> > > and
>> > > > > SUREFIRE-1614), you will have them but no multiple releases (not
>> > > > effective
>> > > > > in the perspectives of out spare time).
>> > > > > We need people like you who will support us in 3.0.0-M4. This is
>> the
>> > > main
>> > > > > goal.
>> > > > > The issues SUREFIRE-1546 and SUREFIRE-1614 will be delivered to
>> you,
>> > > but
>> > > > no
>> > > > > more and not less.
>> > > > > The thing is how you will participate by your hands in Java code.
>> The
>> > > > > result depends on you.
>> > > > > But again, this what we solve here is not important for ASF. It is
>> > > > > important for you and your agenda.
>> > > > > For the project is important the deal we made several years ago,
>> when
>> > > we
>> > > > > planned to provide Extensions API for the Users. To get there we
>> need
>> > > to
>> > > > > unfortunately rework internal code in Surefire project which takes
>> > > > really a
>> > > > > lots of time and spends private energy, and thus 2.22.2 is less
>> > > important
>> > > > > from this perspective. We have to support long standing vision but
>> > the
>> > > > > version 2.22.2 is something short lasting which you and some
>> Spring
>> > > guys
>> > > > > wanted due to they have a problem* with their own internal rules*
>> and
>> > > > > technically Spring project can solve this problem with 3.0.0-M3.
>> > > > Therefore
>> > > > > we are wasting the time if we write the code for you. Therefore
>> you
>> > > > should
>> > > > > provide pull request by yourself as this is OSS and we can make a
>> > code
>> > > > > review. But our effort would be really only short time relevant
>> if we
>> > > > > dedicate too much time in 2.22.2 with these two Jira issues. We
>> have
>> > > few
>> > > > > active Java developers and "stealing" them for your activity means
>> > that
>> > > > we
>> > > > > are not effective and slow. Therefore, Stephane pls prepare the
>> > commits
>> > > > on
>> > > > > your responsibility on GitHub in your pull request and we can
>> invest
>> > > the
>> > > > > time to check it including the build check and cutting the release
>> > > > version.
>> > > > >
>> > > > > T
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Wed, Mar 27, 2019 at 8:11 AM Stephane Nicoll <
>> > > > stephane.nic...@gmail.com>
>> > > > > wrote:
>> > > > >
>> > > > > > On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana <
>> > > tibordig...@apache.org>
>> > > > > > wrote:
>> > > > > >
>> > > > > > > Stephane,
>> > > > > > >
>> > > > > > > >> I wanted to make sure that the JUnit5 story was functional
>> > > > > > >
>> > > > > > > I really don't like politics.
>> > > > > >
>> > > > > >
>> > > > > > What's that supposed to mean? If you want to quote something,
>> > please
>> > > > quote
>> > > > > > the full sentence. The full sentence is *"I wanted to make sure
>> > that
>> > > > the
>> > > > > > JUnit5 story was functional with the vintage engine and the
>> current
>> > > GA
>> > > > of
>> > > > > > surefire." *which I believe is an accurate description of the
>> > current
>> > > > > > situation.
>> > > > > >
>> > > > > >
>> > > > > > > Did you see SUREFIRE-1614?
>> > > > > >
>> > > > > >
>> > > > > > I did, that's the issue I backported. What are you talking
>> about?
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > > It really does not
>> > > > > > > break functionality (only affects logger) and SUREFIRE-1614 is
>> > not
>> > > > worth
>> > > > > > of
>> > > > > > > making release with single improvement. If you want to be
>> > > > 

Re: Surefire maintenance release

[Enrico Olivelli]

I have created a PR for your work Stephane
https://github.com/apache/maven-surefire/pull/225

I will do my best
I am still new to the release procedure, never cut a release for surefire
and we usually are only cutting releases from master.


Enrico



Il gio 28 mar 2019, 00:34 Olivier Lamy  ha scritto:

> On Thu, 28 Mar 2019 at 03:14, Enrico Olivelli  wrote:
>
> > Il mer 27 mar 2019, 18:10 Tibor Digana  ha
> > scritto:
> >
> > > Enrico, what i maintenance release for you, 2.22.2-M1?
> > >
> >
> > 2.22.2 without suffix
> >
>
> +1
> @Tibor if you are too busy maybe Enrico can cut the release if he has time.
>
>
> >
> >
> > Enrico
> >
> > >
> > >
> > >
> > >
> > > On Wed, Mar 27, 2019 at 6:07 PM Enrico Olivelli 
> > > wrote:
> > >
> > > > Stephane
> > > > thank you so much.
> > > > I think we will be able to cut a maintenaince release soon with your
> > > > branch.
> > > >
> > > > Maybe you can join us in chat with https://s.apache.org/slack-invite
> > > > #maven  channel
> > > >
> > > >
> > > > Enrico
> > > >
> > > > Il giorno mer 27 mar 2019 alle ore 15:45 Tibor Digana
> > > >  ha scritto:
> > > > >
> > > > > Stephane, What exists in our agreement are two issues
> (SUREFIRE-1546
> > > and
> > > > > SUREFIRE-1614), you will have them but no multiple releases (not
> > > > effective
> > > > > in the perspectives of out spare time).
> > > > > We need people like you who will support us in 3.0.0-M4. This is
> the
> > > main
> > > > > goal.
> > > > > The issues SUREFIRE-1546 and SUREFIRE-1614 will be delivered to
> you,
> > > but
> > > > no
> > > > > more and not less.
> > > > > The thing is how you will participate by your hands in Java code.
> The
> > > > > result depends on you.
> > > > > But again, this what we solve here is not important for ASF. It is
> > > > > important for you and your agenda.
> > > > > For the project is important the deal we made several years ago,
> when
> > > we
> > > > > planned to provide Extensions API for the Users. To get there we
> need
> > > to
> > > > > unfortunately rework internal code in Surefire project which takes
> > > > really a
> > > > > lots of time and spends private energy, and thus 2.22.2 is less
> > > important
> > > > > from this perspective. We have to support long standing vision but
> > the
> > > > > version 2.22.2 is something short lasting which you and some Spring
> > > guys
> > > > > wanted due to they have a problem* with their own internal rules*
> and
> > > > > technically Spring project can solve this problem with 3.0.0-M3.
> > > > Therefore
> > > > > we are wasting the time if we write the code for you. Therefore you
> > > > should
> > > > > provide pull request by yourself as this is OSS and we can make a
> > code
> > > > > review. But our effort would be really only short time relevant if
> we
> > > > > dedicate too much time in 2.22.2 with these two Jira issues. We
> have
> > > few
> > > > > active Java developers and "stealing" them for your activity means
> > that
> > > > we
> > > > > are not effective and slow. Therefore, Stephane pls prepare the
> > commits
> > > > on
> > > > > your responsibility on GitHub in your pull request and we can
> invest
> > > the
> > > > > time to check it including the build check and cutting the release
> > > > version.
> > > > >
> > > > > T
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Mar 27, 2019 at 8:11 AM Stephane Nicoll <
> > > > stephane.nic...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana <
> > > tibordig...@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > Stephane,
> > > > > > >
> > > > > > > >> I wanted to make sure that the JUnit5 story was functional
> > > > > > >
> > > > > > > I really don't like politics.
> > > > > >
> > > > > >
> > > > > > What's that supposed to mean? If you want to quote something,
> > please
> > > > quote
> > > > > > the full sentence. The full sentence is *"I wanted to make sure
> > that
> > > > the
> > > > > > JUnit5 story was functional with the vintage engine and the
> current
> > > GA
> > > > of
> > > > > > surefire." *which I believe is an accurate description of the
> > current
> > > > > > situation.
> > > > > >
> > > > > >
> > > > > > > Did you see SUREFIRE-1614?
> > > > > >
> > > > > >
> > > > > > I did, that's the issue I backported. What are you talking about?
> > > > > >
> > > > > >
> > > > > >
> > > > > > > It really does not
> > > > > > > break functionality (only affects logger) and SUREFIRE-1614 is
> > not
> > > > worth
> > > > > > of
> > > > > > > making release with single improvement. If you want to be
> > > > consistent, you
> > > > > > > should stand on your original list of issues in your first
> email
> > > and
> > > > this
> > > > > > > is: SUREFIRE-1546 and SUREFIRE-1614.
> > > > > > >
> > > > > >
> > > > > > I wanted to but someone from the JUnit team said that backporting
> > > that
> > > > > > second issue "makes no sense". What am I supposed to do with 

Re: Surefire maintenance release

[Olivier Lamy]

On Thu, 28 Mar 2019 at 03:14, Enrico Olivelli  wrote:

> Il mer 27 mar 2019, 18:10 Tibor Digana  ha
> scritto:
>
> > Enrico, what i maintenance release for you, 2.22.2-M1?
> >
>
> 2.22.2 without suffix
>

+1
@Tibor if you are too busy maybe Enrico can cut the release if he has time.


>
>
> Enrico
>
> >
> >
> >
> >
> > On Wed, Mar 27, 2019 at 6:07 PM Enrico Olivelli 
> > wrote:
> >
> > > Stephane
> > > thank you so much.
> > > I think we will be able to cut a maintenaince release soon with your
> > > branch.
> > >
> > > Maybe you can join us in chat with https://s.apache.org/slack-invite
> > > #maven  channel
> > >
> > >
> > > Enrico
> > >
> > > Il giorno mer 27 mar 2019 alle ore 15:45 Tibor Digana
> > >  ha scritto:
> > > >
> > > > Stephane, What exists in our agreement are two issues (SUREFIRE-1546
> > and
> > > > SUREFIRE-1614), you will have them but no multiple releases (not
> > > effective
> > > > in the perspectives of out spare time).
> > > > We need people like you who will support us in 3.0.0-M4. This is the
> > main
> > > > goal.
> > > > The issues SUREFIRE-1546 and SUREFIRE-1614 will be delivered to you,
> > but
> > > no
> > > > more and not less.
> > > > The thing is how you will participate by your hands in Java code. The
> > > > result depends on you.
> > > > But again, this what we solve here is not important for ASF. It is
> > > > important for you and your agenda.
> > > > For the project is important the deal we made several years ago, when
> > we
> > > > planned to provide Extensions API for the Users. To get there we need
> > to
> > > > unfortunately rework internal code in Surefire project which takes
> > > really a
> > > > lots of time and spends private energy, and thus 2.22.2 is less
> > important
> > > > from this perspective. We have to support long standing vision but
> the
> > > > version 2.22.2 is something short lasting which you and some Spring
> > guys
> > > > wanted due to they have a problem* with their own internal rules* and
> > > > technically Spring project can solve this problem with 3.0.0-M3.
> > > Therefore
> > > > we are wasting the time if we write the code for you. Therefore you
> > > should
> > > > provide pull request by yourself as this is OSS and we can make a
> code
> > > > review. But our effort would be really only short time relevant if we
> > > > dedicate too much time in 2.22.2 with these two Jira issues. We have
> > few
> > > > active Java developers and "stealing" them for your activity means
> that
> > > we
> > > > are not effective and slow. Therefore, Stephane pls prepare the
> commits
> > > on
> > > > your responsibility on GitHub in your pull request and we can invest
> > the
> > > > time to check it including the build check and cutting the release
> > > version.
> > > >
> > > > T
> > > >
> > > >
> > > >
> > > > On Wed, Mar 27, 2019 at 8:11 AM Stephane Nicoll <
> > > stephane.nic...@gmail.com>
> > > > wrote:
> > > >
> > > > > On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana <
> > tibordig...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Stephane,
> > > > > >
> > > > > > >> I wanted to make sure that the JUnit5 story was functional
> > > > > >
> > > > > > I really don't like politics.
> > > > >
> > > > >
> > > > > What's that supposed to mean? If you want to quote something,
> please
> > > quote
> > > > > the full sentence. The full sentence is *"I wanted to make sure
> that
> > > the
> > > > > JUnit5 story was functional with the vintage engine and the current
> > GA
> > > of
> > > > > surefire." *which I believe is an accurate description of the
> current
> > > > > situation.
> > > > >
> > > > >
> > > > > > Did you see SUREFIRE-1614?
> > > > >
> > > > >
> > > > > I did, that's the issue I backported. What are you talking about?
> > > > >
> > > > >
> > > > >
> > > > > > It really does not
> > > > > > break functionality (only affects logger) and SUREFIRE-1614 is
> not
> > > worth
> > > > > of
> > > > > > making release with single improvement. If you want to be
> > > consistent, you
> > > > > > should stand on your original list of issues in your first email
> > and
> > > this
> > > > > > is: SUREFIRE-1546 and SUREFIRE-1614.
> > > > > >
> > > > >
> > > > > I wanted to but someone from the JUnit team said that backporting
> > that
> > > > > second issue "makes no sense". What am I supposed to do with that
> > > > > information exactly?
> > > > >
> > > > > At the end of the day, you decide what the outcome of this request
> > has
> > > to
> > > > > be. Spring Boot can't upgrade its base usage to JUnit 5 because it
> > > does not
> > > > > work properly when combined with the vintage engine. That's all I
> am
> > > trying
> > > > > to fix.
> > > > >
> > > > > I also think that It doesn't matter how many issues you have fixed
> > in a
> > > > > maintenance release as long as that helps the community. Others
> > members
> > > > > here have expressed a +1 to that proposal.
> > > > >
> > > > > Thanks,
> > > > 

Re: Surefire maintenance release

[Christian Stein]

On Wed, Mar 27, 2019 at 6:14 PM Enrico Olivelli  wrote:

> Il mer 27 mar 2019, 18:10 Tibor Digana  ha
> scritto:
>
> > Enrico, what i maintenance release for you, 2.22.2-M1?
> >
>
> 2.22.2 without suffix
>
>
This.

Re: Surefire maintenance release

[Enrico Olivelli]

Il mer 27 mar 2019, 18:10 Tibor Digana  ha scritto:

> Enrico, what i maintenance release for you, 2.22.2-M1?
>

2.22.2 without suffix


Enrico

>
>
>
>
> On Wed, Mar 27, 2019 at 6:07 PM Enrico Olivelli 
> wrote:
>
> > Stephane
> > thank you so much.
> > I think we will be able to cut a maintenaince release soon with your
> > branch.
> >
> > Maybe you can join us in chat with https://s.apache.org/slack-invite
> > #maven  channel
> >
> >
> > Enrico
> >
> > Il giorno mer 27 mar 2019 alle ore 15:45 Tibor Digana
> >  ha scritto:
> > >
> > > Stephane, What exists in our agreement are two issues (SUREFIRE-1546
> and
> > > SUREFIRE-1614), you will have them but no multiple releases (not
> > effective
> > > in the perspectives of out spare time).
> > > We need people like you who will support us in 3.0.0-M4. This is the
> main
> > > goal.
> > > The issues SUREFIRE-1546 and SUREFIRE-1614 will be delivered to you,
> but
> > no
> > > more and not less.
> > > The thing is how you will participate by your hands in Java code. The
> > > result depends on you.
> > > But again, this what we solve here is not important for ASF. It is
> > > important for you and your agenda.
> > > For the project is important the deal we made several years ago, when
> we
> > > planned to provide Extensions API for the Users. To get there we need
> to
> > > unfortunately rework internal code in Surefire project which takes
> > really a
> > > lots of time and spends private energy, and thus 2.22.2 is less
> important
> > > from this perspective. We have to support long standing vision but the
> > > version 2.22.2 is something short lasting which you and some Spring
> guys
> > > wanted due to they have a problem* with their own internal rules* and
> > > technically Spring project can solve this problem with 3.0.0-M3.
> > Therefore
> > > we are wasting the time if we write the code for you. Therefore you
> > should
> > > provide pull request by yourself as this is OSS and we can make a code
> > > review. But our effort would be really only short time relevant if we
> > > dedicate too much time in 2.22.2 with these two Jira issues. We have
> few
> > > active Java developers and "stealing" them for your activity means that
> > we
> > > are not effective and slow. Therefore, Stephane pls prepare the commits
> > on
> > > your responsibility on GitHub in your pull request and we can invest
> the
> > > time to check it including the build check and cutting the release
> > version.
> > >
> > > T
> > >
> > >
> > >
> > > On Wed, Mar 27, 2019 at 8:11 AM Stephane Nicoll <
> > stephane.nic...@gmail.com>
> > > wrote:
> > >
> > > > On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana <
> tibordig...@apache.org>
> > > > wrote:
> > > >
> > > > > Stephane,
> > > > >
> > > > > >> I wanted to make sure that the JUnit5 story was functional
> > > > >
> > > > > I really don't like politics.
> > > >
> > > >
> > > > What's that supposed to mean? If you want to quote something, please
> > quote
> > > > the full sentence. The full sentence is *"I wanted to make sure that
> > the
> > > > JUnit5 story was functional with the vintage engine and the current
> GA
> > of
> > > > surefire." *which I believe is an accurate description of the current
> > > > situation.
> > > >
> > > >
> > > > > Did you see SUREFIRE-1614?
> > > >
> > > >
> > > > I did, that's the issue I backported. What are you talking about?
> > > >
> > > >
> > > >
> > > > > It really does not
> > > > > break functionality (only affects logger) and SUREFIRE-1614 is not
> > worth
> > > > of
> > > > > making release with single improvement. If you want to be
> > consistent, you
> > > > > should stand on your original list of issues in your first email
> and
> > this
> > > > > is: SUREFIRE-1546 and SUREFIRE-1614.
> > > > >
> > > >
> > > > I wanted to but someone from the JUnit team said that backporting
> that
> > > > second issue "makes no sense". What am I supposed to do with that
> > > > information exactly?
> > > >
> > > > At the end of the day, you decide what the outcome of this request
> has
> > to
> > > > be. Spring Boot can't upgrade its base usage to JUnit 5 because it
> > does not
> > > > work properly when combined with the vintage engine. That's all I am
> > trying
> > > > to fix.
> > > >
> > > > I also think that It doesn't matter how many issues you have fixed
> in a
> > > > maintenance release as long as that helps the community. Others
> members
> > > > here have expressed a +1 to that proposal.
> > > >
> > > > Thanks,
> > > > S.
> > > >
> > > >
> > > >
> > > > > We in Slack discuss technical details what we do in milestone
> > versions.
> > > > > Enrico and Christian are active developers but we need to have more
> > > > > developers like you Stephane and I would appreciate to have
> > additionally
> > > > > the previous developers on the board as well and grow the team,
> i.e.
> > > > > Andreas and Kristian.
> > > > >
> > > > > Cheers
> > > > > Tibor
> > > > >
> 

Re: Surefire maintenance release

[Tibor Digana]

Enrico, what i maintenance release for you, 2.22.2-M1?


On Wed, Mar 27, 2019 at 6:07 PM Enrico Olivelli  wrote:

> Stephane
> thank you so much.
> I think we will be able to cut a maintenaince release soon with your
> branch.
>
> Maybe you can join us in chat with https://s.apache.org/slack-invite
> #maven  channel
>
>
> Enrico
>
> Il giorno mer 27 mar 2019 alle ore 15:45 Tibor Digana
>  ha scritto:
> >
> > Stephane, What exists in our agreement are two issues (SUREFIRE-1546 and
> > SUREFIRE-1614), you will have them but no multiple releases (not
> effective
> > in the perspectives of out spare time).
> > We need people like you who will support us in 3.0.0-M4. This is the main
> > goal.
> > The issues SUREFIRE-1546 and SUREFIRE-1614 will be delivered to you, but
> no
> > more and not less.
> > The thing is how you will participate by your hands in Java code. The
> > result depends on you.
> > But again, this what we solve here is not important for ASF. It is
> > important for you and your agenda.
> > For the project is important the deal we made several years ago, when we
> > planned to provide Extensions API for the Users. To get there we need to
> > unfortunately rework internal code in Surefire project which takes
> really a
> > lots of time and spends private energy, and thus 2.22.2 is less important
> > from this perspective. We have to support long standing vision but the
> > version 2.22.2 is something short lasting which you and some Spring guys
> > wanted due to they have a problem* with their own internal rules* and
> > technically Spring project can solve this problem with 3.0.0-M3.
> Therefore
> > we are wasting the time if we write the code for you. Therefore you
> should
> > provide pull request by yourself as this is OSS and we can make a code
> > review. But our effort would be really only short time relevant if we
> > dedicate too much time in 2.22.2 with these two Jira issues. We have few
> > active Java developers and "stealing" them for your activity means that
> we
> > are not effective and slow. Therefore, Stephane pls prepare the commits
> on
> > your responsibility on GitHub in your pull request and we can invest the
> > time to check it including the build check and cutting the release
> version.
> >
> > T
> >
> >
> >
> > On Wed, Mar 27, 2019 at 8:11 AM Stephane Nicoll <
> stephane.nic...@gmail.com>
> > wrote:
> >
> > > On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana 
> > > wrote:
> > >
> > > > Stephane,
> > > >
> > > > >> I wanted to make sure that the JUnit5 story was functional
> > > >
> > > > I really don't like politics.
> > >
> > >
> > > What's that supposed to mean? If you want to quote something, please
> quote
> > > the full sentence. The full sentence is *"I wanted to make sure that
> the
> > > JUnit5 story was functional with the vintage engine and the current GA
> of
> > > surefire." *which I believe is an accurate description of the current
> > > situation.
> > >
> > >
> > > > Did you see SUREFIRE-1614?
> > >
> > >
> > > I did, that's the issue I backported. What are you talking about?
> > >
> > >
> > >
> > > > It really does not
> > > > break functionality (only affects logger) and SUREFIRE-1614 is not
> worth
> > > of
> > > > making release with single improvement. If you want to be
> consistent, you
> > > > should stand on your original list of issues in your first email and
> this
> > > > is: SUREFIRE-1546 and SUREFIRE-1614.
> > > >
> > >
> > > I wanted to but someone from the JUnit team said that backporting that
> > > second issue "makes no sense". What am I supposed to do with that
> > > information exactly?
> > >
> > > At the end of the day, you decide what the outcome of this request has
> to
> > > be. Spring Boot can't upgrade its base usage to JUnit 5 because it
> does not
> > > work properly when combined with the vintage engine. That's all I am
> trying
> > > to fix.
> > >
> > > I also think that It doesn't matter how many issues you have fixed in a
> > > maintenance release as long as that helps the community. Others members
> > > here have expressed a +1 to that proposal.
> > >
> > > Thanks,
> > > S.
> > >
> > >
> > >
> > > > We in Slack discuss technical details what we do in milestone
> versions.
> > > > Enrico and Christian are active developers but we need to have more
> > > > developers like you Stephane and I would appreciate to have
> additionally
> > > > the previous developers on the board as well and grow the team, i.e.
> > > > Andreas and Kristian.
> > > >
> > > > Cheers
> > > > Tibor
> > > >
> > > >
> > > > On Mon, Mar 25, 2019 at 5:11 PM Stephane Nicoll <
> > > stephane.nic...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Thanks for having a look Tibor!
> > > > >
> > > > > On Mon, Mar 25, 2019 at 4:37 PM Tibor Digana <
> tibordig...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > The diff looks good.
> > > > > >
> > > > > > Stephane, I guess this only 50% work you wanted to have.
> > > > > 

Re: Surefire maintenance release

[Enrico Olivelli]

Stephane
thank you so much.
I think we will be able to cut a maintenaince release soon with your branch.

Maybe you can join us in chat with https://s.apache.org/slack-invite
#maven channel


Enrico

Il giorno mer 27 mar 2019 alle ore 15:45 Tibor Digana
 ha scritto:
>
> Stephane, What exists in our agreement are two issues (SUREFIRE-1546 and
> SUREFIRE-1614), you will have them but no multiple releases (not effective
> in the perspectives of out spare time).
> We need people like you who will support us in 3.0.0-M4. This is the main
> goal.
> The issues SUREFIRE-1546 and SUREFIRE-1614 will be delivered to you, but no
> more and not less.
> The thing is how you will participate by your hands in Java code. The
> result depends on you.
> But again, this what we solve here is not important for ASF. It is
> important for you and your agenda.
> For the project is important the deal we made several years ago, when we
> planned to provide Extensions API for the Users. To get there we need to
> unfortunately rework internal code in Surefire project which takes really a
> lots of time and spends private energy, and thus 2.22.2 is less important
> from this perspective. We have to support long standing vision but the
> version 2.22.2 is something short lasting which you and some Spring guys
> wanted due to they have a problem* with their own internal rules* and
> technically Spring project can solve this problem with 3.0.0-M3. Therefore
> we are wasting the time if we write the code for you. Therefore you should
> provide pull request by yourself as this is OSS and we can make a code
> review. But our effort would be really only short time relevant if we
> dedicate too much time in 2.22.2 with these two Jira issues. We have few
> active Java developers and "stealing" them for your activity means that we
> are not effective and slow. Therefore, Stephane pls prepare the commits on
> your responsibility on GitHub in your pull request and we can invest the
> time to check it including the build check and cutting the release version.
>
> T
>
>
>
> On Wed, Mar 27, 2019 at 8:11 AM Stephane Nicoll 
> wrote:
>
> > On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana 
> > wrote:
> >
> > > Stephane,
> > >
> > > >> I wanted to make sure that the JUnit5 story was functional
> > >
> > > I really don't like politics.
> >
> >
> > What's that supposed to mean? If you want to quote something, please quote
> > the full sentence. The full sentence is *"I wanted to make sure that the
> > JUnit5 story was functional with the vintage engine and the current GA of
> > surefire." *which I believe is an accurate description of the current
> > situation.
> >
> >
> > > Did you see SUREFIRE-1614?
> >
> >
> > I did, that's the issue I backported. What are you talking about?
> >
> >
> >
> > > It really does not
> > > break functionality (only affects logger) and SUREFIRE-1614 is not worth
> > of
> > > making release with single improvement. If you want to be consistent, you
> > > should stand on your original list of issues in your first email and this
> > > is: SUREFIRE-1546 and SUREFIRE-1614.
> > >
> >
> > I wanted to but someone from the JUnit team said that backporting that
> > second issue "makes no sense". What am I supposed to do with that
> > information exactly?
> >
> > At the end of the day, you decide what the outcome of this request has to
> > be. Spring Boot can't upgrade its base usage to JUnit 5 because it does not
> > work properly when combined with the vintage engine. That's all I am trying
> > to fix.
> >
> > I also think that It doesn't matter how many issues you have fixed in a
> > maintenance release as long as that helps the community. Others members
> > here have expressed a +1 to that proposal.
> >
> > Thanks,
> > S.
> >
> >
> >
> > > We in Slack discuss technical details what we do in milestone versions.
> > > Enrico and Christian are active developers but we need to have more
> > > developers like you Stephane and I would appreciate to have additionally
> > > the previous developers on the board as well and grow the team, i.e.
> > > Andreas and Kristian.
> > >
> > > Cheers
> > > Tibor
> > >
> > >
> > > On Mon, Mar 25, 2019 at 5:11 PM Stephane Nicoll <
> > stephane.nic...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Thanks for having a look Tibor!
> > > >
> > > > On Mon, Mar 25, 2019 at 4:37 PM Tibor Digana 
> > > > wrote:
> > > >
> > > > > The diff looks good.
> > > > >
> > > > > Stephane, I guess this only 50% work you wanted to have.
> > > > >
> > > >
> > > > I wanted to make sure that the JUnit5 story was functional with the
> > > vintage
> > > > engine and the current GA of surefire. It looks like this change does
> > the
> > > > job for us.
> > > >
> > > > As for the other change, I read Christan's reply, quoting below:
> > > >
> > > >
> > > >
> > > >
> > > > *supporting "@DisplayName" and therefore also
> > > > backportinghttps://issues.apache.org/jira/browse/SUREFIRE-1546
> > > > 

Re: Surefire maintenance release

[Tibor Digana]

Stephane, What exists in our agreement are two issues (SUREFIRE-1546 and
SUREFIRE-1614), you will have them but no multiple releases (not effective
in the perspectives of out spare time).
We need people like you who will support us in 3.0.0-M4. This is the main
goal.
The issues SUREFIRE-1546 and SUREFIRE-1614 will be delivered to you, but no
more and not less.
The thing is how you will participate by your hands in Java code. The
result depends on you.
But again, this what we solve here is not important for ASF. It is
important for you and your agenda.
For the project is important the deal we made several years ago, when we
planned to provide Extensions API for the Users. To get there we need to
unfortunately rework internal code in Surefire project which takes really a
lots of time and spends private energy, and thus 2.22.2 is less important
from this perspective. We have to support long standing vision but the
version 2.22.2 is something short lasting which you and some Spring guys
wanted due to they have a problem* with their own internal rules* and
technically Spring project can solve this problem with 3.0.0-M3. Therefore
we are wasting the time if we write the code for you. Therefore you should
provide pull request by yourself as this is OSS and we can make a code
review. But our effort would be really only short time relevant if we
dedicate too much time in 2.22.2 with these two Jira issues. We have few
active Java developers and "stealing" them for your activity means that we
are not effective and slow. Therefore, Stephane pls prepare the commits on
your responsibility on GitHub in your pull request and we can invest the
time to check it including the build check and cutting the release version.

T



On Wed, Mar 27, 2019 at 8:11 AM Stephane Nicoll 
wrote:

> On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana 
> wrote:
>
> > Stephane,
> >
> > >> I wanted to make sure that the JUnit5 story was functional
> >
> > I really don't like politics.
>
>
> What's that supposed to mean? If you want to quote something, please quote
> the full sentence. The full sentence is *"I wanted to make sure that the
> JUnit5 story was functional with the vintage engine and the current GA of
> surefire." *which I believe is an accurate description of the current
> situation.
>
>
> > Did you see SUREFIRE-1614?
>
>
> I did, that's the issue I backported. What are you talking about?
>
>
>
> > It really does not
> > break functionality (only affects logger) and SUREFIRE-1614 is not worth
> of
> > making release with single improvement. If you want to be consistent, you
> > should stand on your original list of issues in your first email and this
> > is: SUREFIRE-1546 and SUREFIRE-1614.
> >
>
> I wanted to but someone from the JUnit team said that backporting that
> second issue "makes no sense". What am I supposed to do with that
> information exactly?
>
> At the end of the day, you decide what the outcome of this request has to
> be. Spring Boot can't upgrade its base usage to JUnit 5 because it does not
> work properly when combined with the vintage engine. That's all I am trying
> to fix.
>
> I also think that It doesn't matter how many issues you have fixed in a
> maintenance release as long as that helps the community. Others members
> here have expressed a +1 to that proposal.
>
> Thanks,
> S.
>
>
>
> > We in Slack discuss technical details what we do in milestone versions.
> > Enrico and Christian are active developers but we need to have more
> > developers like you Stephane and I would appreciate to have additionally
> > the previous developers on the board as well and grow the team, i.e.
> > Andreas and Kristian.
> >
> > Cheers
> > Tibor
> >
> >
> > On Mon, Mar 25, 2019 at 5:11 PM Stephane Nicoll <
> stephane.nic...@gmail.com
> > >
> > wrote:
> >
> > > Thanks for having a look Tibor!
> > >
> > > On Mon, Mar 25, 2019 at 4:37 PM Tibor Digana 
> > > wrote:
> > >
> > > > The diff looks good.
> > > >
> > > > Stephane, I guess this only 50% work you wanted to have.
> > > >
> > >
> > > I wanted to make sure that the JUnit5 story was functional with the
> > vintage
> > > engine and the current GA of surefire. It looks like this change does
> the
> > > job for us.
> > >
> > > As for the other change, I read Christan's reply, quoting below:
> > >
> > >
> > >
> > >
> > > *supporting "@DisplayName" and therefore also
> > > backportinghttps://issues.apache.org/jira/browse/SUREFIRE-1546
> > >  to the 2.x
> branch
> > > makesalmost *no* sense to me. *
> > >
> > > As you've explained, backporting this change would be more challenging
> > and
> > > it looks like it isn't a blocker in its current form anyway so I have
> no
> > > opinion as how we should proceed. If the team feels that backporting it
> > is
> > > important, I can give it another go.
> > >
> > > Cheers,
> > > S.
> > >
> > >
> > >
> > >
> > > >
> > > > Let's not make too many versions because this would be a precedent.
> > 

Re: Surefire maintenance release

[Stephane Nicoll]

On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana 
wrote:

> Stephane,
>
> >> I wanted to make sure that the JUnit5 story was functional
>
> I really don't like politics.


What's that supposed to mean? If you want to quote something, please quote
the full sentence. The full sentence is *"I wanted to make sure that the
JUnit5 story was functional with the vintage engine and the current GA of
surefire." *which I believe is an accurate description of the current
situation.


> Did you see SUREFIRE-1614?


I did, that's the issue I backported. What are you talking about?



> It really does not
> break functionality (only affects logger) and SUREFIRE-1614 is not worth of
> making release with single improvement. If you want to be consistent, you
> should stand on your original list of issues in your first email and this
> is: SUREFIRE-1546 and SUREFIRE-1614.
>

I wanted to but someone from the JUnit team said that backporting that
second issue "makes no sense". What am I supposed to do with that
information exactly?

At the end of the day, you decide what the outcome of this request has to
be. Spring Boot can't upgrade its base usage to JUnit 5 because it does not
work properly when combined with the vintage engine. That's all I am trying
to fix.

I also think that It doesn't matter how many issues you have fixed in a
maintenance release as long as that helps the community. Others members
here have expressed a +1 to that proposal.

Thanks,
S.



> We in Slack discuss technical details what we do in milestone versions.
> Enrico and Christian are active developers but we need to have more
> developers like you Stephane and I would appreciate to have additionally
> the previous developers on the board as well and grow the team, i.e.
> Andreas and Kristian.
>
> Cheers
> Tibor
>
>
> On Mon, Mar 25, 2019 at 5:11 PM Stephane Nicoll  >
> wrote:
>
> > Thanks for having a look Tibor!
> >
> > On Mon, Mar 25, 2019 at 4:37 PM Tibor Digana 
> > wrote:
> >
> > > The diff looks good.
> > >
> > > Stephane, I guess this only 50% work you wanted to have.
> > >
> >
> > I wanted to make sure that the JUnit5 story was functional with the
> vintage
> > engine and the current GA of surefire. It looks like this change does the
> > job for us.
> >
> > As for the other change, I read Christan's reply, quoting below:
> >
> >
> >
> >
> > *supporting "@DisplayName" and therefore also
> > backportinghttps://issues.apache.org/jira/browse/SUREFIRE-1546
> >  to the 2.x branch
> > makesalmost *no* sense to me. *
> >
> > As you've explained, backporting this change would be more challenging
> and
> > it looks like it isn't a blocker in its current form anyway so I have no
> > opinion as how we should proceed. If the team feels that backporting it
> is
> > important, I can give it another go.
> >
> > Cheers,
> > S.
> >
> >
> >
> >
> > >
> > > Let's not make too many versions because this would be a precedent.
> > >
> > > Question about JUnit5 display name. Currently our solution turns XML
> file
> > > name and XML content to the textual display name and not fully
> qualified
> > > class name. This means that the class name would not appear in the file
> > > name of XML report. We want to give the user chance to configure this
> in
> > > 3.0.0-M4 and alter this behavior. So it's good to make a consensus here
> > and
> > > agree on it. I prefer more complex configuration with MOJO parameter as
> > > Object and not boolean. Since currently we have
> > > *StatelessXmlReporter.java*,
> > > I prefer opening the internal impl with this parameter in plugin
> > > configuration and alter the behavior in POM or in user's Java code:
> > >
> > >  > > impl="org.apace.maven.plugin.surefire.report.StatelessXmlReporter">
> 
> > > human readable 
> > > human readable
> > > human readable
> > > 
> > >
> > > If somebody prefers streaming the report on the fly to YAML, we can
> > provide
> > > same for Stateful reporter interface.
> > > Unfortunately all three attributes of the object must have same
> settings
> > in
> > > 2.x. The reason is that it is not possible to have it so sooth behaving
> > in
> > > 2.x. We in 3.0 rework internal implementation, a lot of classes, to
> > support
> > > many new features/fixes (support this in JUnit5 Provider and
> additionally
> > > to resolve critical bugs, ...).
> > > But the benefit in this concept is that we define it once and we won't
> > have
> > > any reason to change this concept again in another version.
> > > Makes sense?
> > >
> > > Cheers
> > > Tibor
> > >
> > > On Mon, Mar 25, 2019 at 3:38 PM Stephane Nicoll <
> > stephane.nic...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hey,
> > > >
> > > > Can someone working on surefire confirm the interest of creating that
> > > > branch in the main repo and kick-off a release if a review is
> > > satisfactory?
> > > >
> > > > Thanks!
> > > > S.
> > > >
> > > >
> > > > On Wed, Mar 13, 2019 at 4:09 PM Stephane 

Re: Surefire maintenance release

[Tibor Digana]

Stephane,

>> I wanted to make sure that the JUnit5 story was functional

I really don't like politics. Did you see SUREFIRE-1614? It really does not
break functionality (only affects logger) and SUREFIRE-1614 is not worth of
making release with single improvement. If you want to be consistent, you
should stand on your original list of issues in your first email and this
is: SUREFIRE-1546 and SUREFIRE-1614.

We in Slack discuss technical details what we do in milestone versions.
Enrico and Christian are active developers but we need to have more
developers like you Stephane and I would appreciate to have additionally
the previous developers on the board as well and grow the team, i.e.
Andreas and Kristian.

Cheers
Tibor


On Mon, Mar 25, 2019 at 5:11 PM Stephane Nicoll 
wrote:

> Thanks for having a look Tibor!
>
> On Mon, Mar 25, 2019 at 4:37 PM Tibor Digana 
> wrote:
>
> > The diff looks good.
> >
> > Stephane, I guess this only 50% work you wanted to have.
> >
>
> I wanted to make sure that the JUnit5 story was functional with the vintage
> engine and the current GA of surefire. It looks like this change does the
> job for us.
>
> As for the other change, I read Christan's reply, quoting below:
>
>
>
>
> *supporting "@DisplayName" and therefore also
> backportinghttps://issues.apache.org/jira/browse/SUREFIRE-1546
>  to the 2.x branch
> makesalmost *no* sense to me. *
>
> As you've explained, backporting this change would be more challenging and
> it looks like it isn't a blocker in its current form anyway so I have no
> opinion as how we should proceed. If the team feels that backporting it is
> important, I can give it another go.
>
> Cheers,
> S.
>
>
>
>
> >
> > Let's not make too many versions because this would be a precedent.
> >
> > Question about JUnit5 display name. Currently our solution turns XML file
> > name and XML content to the textual display name and not fully qualified
> > class name. This means that the class name would not appear in the file
> > name of XML report. We want to give the user chance to configure this in
> > 3.0.0-M4 and alter this behavior. So it's good to make a consensus here
> and
> > agree on it. I prefer more complex configuration with MOJO parameter as
> > Object and not boolean. Since currently we have
> > *StatelessXmlReporter.java*,
> > I prefer opening the internal impl with this parameter in plugin
> > configuration and alter the behavior in POM or in user's Java code:
> >
> >  > impl="org.apace.maven.plugin.surefire.report.StatelessXmlReporter"> 
> > human readable 
> > human readable
> > human readable
> > 
> >
> > If somebody prefers streaming the report on the fly to YAML, we can
> provide
> > same for Stateful reporter interface.
> > Unfortunately all three attributes of the object must have same settings
> in
> > 2.x. The reason is that it is not possible to have it so sooth behaving
> in
> > 2.x. We in 3.0 rework internal implementation, a lot of classes, to
> support
> > many new features/fixes (support this in JUnit5 Provider and additionally
> > to resolve critical bugs, ...).
> > But the benefit in this concept is that we define it once and we won't
> have
> > any reason to change this concept again in another version.
> > Makes sense?
> >
> > Cheers
> > Tibor
> >
> > On Mon, Mar 25, 2019 at 3:38 PM Stephane Nicoll <
> stephane.nic...@gmail.com
> > >
> > wrote:
> >
> > > Hey,
> > >
> > > Can someone working on surefire confirm the interest of creating that
> > > branch in the main repo and kick-off a release if a review is
> > satisfactory?
> > >
> > > Thanks!
> > > S.
> > >
> > >
> > > On Wed, Mar 13, 2019 at 4:09 PM Stephane Nicoll <
> > stephane.nic...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hey,
> > > >
> > > > I've created a `2.22.x` branch based on the 2.22.1 tag and I've
> > > > cherry-picked the issue we need to get proper support for the vintage
> > > > engine[1]
> > > >
> > > > This 2.22.2-SNAPSHOT works for our purpose so I was wondering if more
> > > > fixes could be backported and/or if someone would like to review
> those
> > > > changes.
> > > >
> > > > Thanks,
> > > > S.
> > > >
> > > >
> > > > [1] https://github.com/snicoll/maven-surefire/tree/2.22.x
> > > >
> > > > On Wed, Feb 27, 2019 at 1:46 PM Tibor Digana  >
> > > > wrote:
> > > >
> > > >> Hi  Stephane,
> > > >>
> > > >> We are talking only about these two commits [1]?
> > > >> Notice that 001e807 modifies file names to the verbose one which
> > breaks
> > > >> backwards compatibility and this should not forcibly (by default)
> > happen
> > > >> in
> > > >> your version/branch.
> > > >> Try to fork the project, make a local branch and then reset HEAD to
> > [2],
> > > >> i.e. git reset --hard 19006aa70f36705f399b8c105a16f636904f00f3
> > > >> And then cherrypick both commits [1].
> > > >> Make sure the order is correct but it won't be so straightforward.
> The
> > > >> tests have to pass (mvn install -P 

Re: Surefire maintenance release

[Stephane Nicoll]

Thanks for having a look Tibor!

On Mon, Mar 25, 2019 at 4:37 PM Tibor Digana  wrote:

> The diff looks good.
>
> Stephane, I guess this only 50% work you wanted to have.
>

I wanted to make sure that the JUnit5 story was functional with the vintage
engine and the current GA of surefire. It looks like this change does the
job for us.

As for the other change, I read Christan's reply, quoting below:




*supporting "@DisplayName" and therefore also
backportinghttps://issues.apache.org/jira/browse/SUREFIRE-1546
 to the 2.x branch
makesalmost *no* sense to me. *

As you've explained, backporting this change would be more challenging and
it looks like it isn't a blocker in its current form anyway so I have no
opinion as how we should proceed. If the team feels that backporting it is
important, I can give it another go.

Cheers,
S.




>
> Let's not make too many versions because this would be a precedent.
>
> Question about JUnit5 display name. Currently our solution turns XML file
> name and XML content to the textual display name and not fully qualified
> class name. This means that the class name would not appear in the file
> name of XML report. We want to give the user chance to configure this in
> 3.0.0-M4 and alter this behavior. So it's good to make a consensus here and
> agree on it. I prefer more complex configuration with MOJO parameter as
> Object and not boolean. Since currently we have
> *StatelessXmlReporter.java*,
> I prefer opening the internal impl with this parameter in plugin
> configuration and alter the behavior in POM or in user's Java code:
>
>  impl="org.apace.maven.plugin.surefire.report.StatelessXmlReporter"> 
> human readable 
> human readable
> human readable
> 
>
> If somebody prefers streaming the report on the fly to YAML, we can provide
> same for Stateful reporter interface.
> Unfortunately all three attributes of the object must have same settings in
> 2.x. The reason is that it is not possible to have it so sooth behaving in
> 2.x. We in 3.0 rework internal implementation, a lot of classes, to support
> many new features/fixes (support this in JUnit5 Provider and additionally
> to resolve critical bugs, ...).
> But the benefit in this concept is that we define it once and we won't have
> any reason to change this concept again in another version.
> Makes sense?
>
> Cheers
> Tibor
>
> On Mon, Mar 25, 2019 at 3:38 PM Stephane Nicoll  >
> wrote:
>
> > Hey,
> >
> > Can someone working on surefire confirm the interest of creating that
> > branch in the main repo and kick-off a release if a review is
> satisfactory?
> >
> > Thanks!
> > S.
> >
> >
> > On Wed, Mar 13, 2019 at 4:09 PM Stephane Nicoll <
> stephane.nic...@gmail.com
> > >
> > wrote:
> >
> > > Hey,
> > >
> > > I've created a `2.22.x` branch based on the 2.22.1 tag and I've
> > > cherry-picked the issue we need to get proper support for the vintage
> > > engine[1]
> > >
> > > This 2.22.2-SNAPSHOT works for our purpose so I was wondering if more
> > > fixes could be backported and/or if someone would like to review those
> > > changes.
> > >
> > > Thanks,
> > > S.
> > >
> > >
> > > [1] https://github.com/snicoll/maven-surefire/tree/2.22.x
> > >
> > > On Wed, Feb 27, 2019 at 1:46 PM Tibor Digana 
> > > wrote:
> > >
> > >> Hi  Stephane,
> > >>
> > >> We are talking only about these two commits [1]?
> > >> Notice that 001e807 modifies file names to the verbose one which
> breaks
> > >> backwards compatibility and this should not forcibly (by default)
> happen
> > >> in
> > >> your version/branch.
> > >> Try to fork the project, make a local branch and then reset HEAD to
> [2],
> > >> i.e. git reset --hard 19006aa70f36705f399b8c105a16f636904f00f3
> > >> And then cherrypick both commits [1].
> > >> Make sure the order is correct but it won't be so straightforward. The
> > >> tests have to pass (mvn install -P run-its).
> > >>
> > >> [1]:
> > >>
> > >>
> >
> https://github.com/apache/maven-surefire/commit/f517d349ede0e15229e3c48f45d10dabc72a3fc9
> > >>
> > >>
> >
> https://github.com/apache/maven-surefire/commit/001e8075b8db7861aaefb5af4c256d919a9b2e7a
> > >>
> > >> [2]:
> > >>
> > >>
> >
> https://github.com/apache/maven-surefire/commit/19006aa70f36705f399b8c105a16f636904f00f3
> > >>
> > >> Cheers
> > >> Tibor
> > >>
> > >> On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll <
> > >> stephane.nic...@gmail.com>
> > >> wrote:
> > >>
> > >> > Hi everyone,
> > >> >
> > >> > It's great to see the progress on Surefire 3.0 and I wanted to reach
> > >> out to
> > >> > discuss a practicable problem with the 2.x line. There are a number
> of
> > >> > fixes for JUnit 5 that are only available in the 3.x line that isn't
> > GA
> > >> > yet. [1][2]
> > >> >
> > >> > Putting my Spring Boot hat for a min, this actually prevents us from
> > >> > upgrading our test support to JUnit 5: our plan is to offer maximum
> > >> > flexibility by providing the vintage engine (so that users can 

Re: Surefire maintenance release

[Tibor Digana]

The diff looks good.

Stephane, I guess this only 50% work you wanted to have.

Let's not make too many versions because this would be a precedent.

Question about JUnit5 display name. Currently our solution turns XML file
name and XML content to the textual display name and not fully qualified
class name. This means that the class name would not appear in the file
name of XML report. We want to give the user chance to configure this in
3.0.0-M4 and alter this behavior. So it's good to make a consensus here and
agree on it. I prefer more complex configuration with MOJO parameter as
Object and not boolean. Since currently we have *StatelessXmlReporter.java*,
I prefer opening the internal impl with this parameter in plugin
configuration and alter the behavior in POM or in user's Java code:

 
human readable 
human readable
human readable


If somebody prefers streaming the report on the fly to YAML, we can provide
same for Stateful reporter interface.
Unfortunately all three attributes of the object must have same settings in
2.x. The reason is that it is not possible to have it so sooth behaving in
2.x. We in 3.0 rework internal implementation, a lot of classes, to support
many new features/fixes (support this in JUnit5 Provider and additionally
to resolve critical bugs, ...).
But the benefit in this concept is that we define it once and we won't have
any reason to change this concept again in another version.
Makes sense?

Cheers
Tibor

On Mon, Mar 25, 2019 at 3:38 PM Stephane Nicoll 
wrote:

> Hey,
>
> Can someone working on surefire confirm the interest of creating that
> branch in the main repo and kick-off a release if a review is satisfactory?
>
> Thanks!
> S.
>
>
> On Wed, Mar 13, 2019 at 4:09 PM Stephane Nicoll  >
> wrote:
>
> > Hey,
> >
> > I've created a `2.22.x` branch based on the 2.22.1 tag and I've
> > cherry-picked the issue we need to get proper support for the vintage
> > engine[1]
> >
> > This 2.22.2-SNAPSHOT works for our purpose so I was wondering if more
> > fixes could be backported and/or if someone would like to review those
> > changes.
> >
> > Thanks,
> > S.
> >
> >
> > [1] https://github.com/snicoll/maven-surefire/tree/2.22.x
> >
> > On Wed, Feb 27, 2019 at 1:46 PM Tibor Digana 
> > wrote:
> >
> >> Hi  Stephane,
> >>
> >> We are talking only about these two commits [1]?
> >> Notice that 001e807 modifies file names to the verbose one which breaks
> >> backwards compatibility and this should not forcibly (by default) happen
> >> in
> >> your version/branch.
> >> Try to fork the project, make a local branch and then reset HEAD to [2],
> >> i.e. git reset --hard 19006aa70f36705f399b8c105a16f636904f00f3
> >> And then cherrypick both commits [1].
> >> Make sure the order is correct but it won't be so straightforward. The
> >> tests have to pass (mvn install -P run-its).
> >>
> >> [1]:
> >>
> >>
> https://github.com/apache/maven-surefire/commit/f517d349ede0e15229e3c48f45d10dabc72a3fc9
> >>
> >>
> https://github.com/apache/maven-surefire/commit/001e8075b8db7861aaefb5af4c256d919a9b2e7a
> >>
> >> [2]:
> >>
> >>
> https://github.com/apache/maven-surefire/commit/19006aa70f36705f399b8c105a16f636904f00f3
> >>
> >> Cheers
> >> Tibor
> >>
> >> On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll <
> >> stephane.nic...@gmail.com>
> >> wrote:
> >>
> >> > Hi everyone,
> >> >
> >> > It's great to see the progress on Surefire 3.0 and I wanted to reach
> >> out to
> >> > discuss a practicable problem with the 2.x line. There are a number of
> >> > fixes for JUnit 5 that are only available in the 3.x line that isn't
> GA
> >> > yet. [1][2]
> >> >
> >> > Putting my Spring Boot hat for a min, this actually prevents us from
> >> > upgrading our test support to JUnit 5: our plan is to offer maximum
> >> > flexibility by providing the vintage engine (so that users can keep
> >> their
> >> > tests and migrate at their own pace).
> >> >
> >> > We can't upgrade to a milestone as our upgrade policy prevents that
> >> > (regardless of how stable this is and especially since backward
> >> > incompatible changes have been pushed to the latest milestone). So
> we're
> >> > kind of stuck.
> >> >
> >> > Would there be an appetite to backport those fixes and release a
> 2.22.2?
> >> >
> >> > Thanks,
> >> > S.
> >> >
> >> > [1] https://issues.apache.org/jira/browse/SUREFIRE-1614
> >> > [2]
> >> https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546
> >> >
> >>
> >
>

Re: Surefire maintenance release

[Tibor Digana]

I'll check the diff.

On Mon, Mar 25, 2019 at 3:38 PM Stephane Nicoll 
wrote:

> Hey,
>
> Can someone working on surefire confirm the interest of creating that
> branch in the main repo and kick-off a release if a review is satisfactory?
>
> Thanks!
> S.
>
>
> On Wed, Mar 13, 2019 at 4:09 PM Stephane Nicoll  >
> wrote:
>
> > Hey,
> >
> > I've created a `2.22.x` branch based on the 2.22.1 tag and I've
> > cherry-picked the issue we need to get proper support for the vintage
> > engine[1]
> >
> > This 2.22.2-SNAPSHOT works for our purpose so I was wondering if more
> > fixes could be backported and/or if someone would like to review those
> > changes.
> >
> > Thanks,
> > S.
> >
> >
> > [1] https://github.com/snicoll/maven-surefire/tree/2.22.x
> >
> > On Wed, Feb 27, 2019 at 1:46 PM Tibor Digana 
> > wrote:
> >
> >> Hi  Stephane,
> >>
> >> We are talking only about these two commits [1]?
> >> Notice that 001e807 modifies file names to the verbose one which breaks
> >> backwards compatibility and this should not forcibly (by default) happen
> >> in
> >> your version/branch.
> >> Try to fork the project, make a local branch and then reset HEAD to [2],
> >> i.e. git reset --hard 19006aa70f36705f399b8c105a16f636904f00f3
> >> And then cherrypick both commits [1].
> >> Make sure the order is correct but it won't be so straightforward. The
> >> tests have to pass (mvn install -P run-its).
> >>
> >> [1]:
> >>
> >>
> https://github.com/apache/maven-surefire/commit/f517d349ede0e15229e3c48f45d10dabc72a3fc9
> >>
> >>
> https://github.com/apache/maven-surefire/commit/001e8075b8db7861aaefb5af4c256d919a9b2e7a
> >>
> >> [2]:
> >>
> >>
> https://github.com/apache/maven-surefire/commit/19006aa70f36705f399b8c105a16f636904f00f3
> >>
> >> Cheers
> >> Tibor
> >>
> >> On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll <
> >> stephane.nic...@gmail.com>
> >> wrote:
> >>
> >> > Hi everyone,
> >> >
> >> > It's great to see the progress on Surefire 3.0 and I wanted to reach
> >> out to
> >> > discuss a practicable problem with the 2.x line. There are a number of
> >> > fixes for JUnit 5 that are only available in the 3.x line that isn't
> GA
> >> > yet. [1][2]
> >> >
> >> > Putting my Spring Boot hat for a min, this actually prevents us from
> >> > upgrading our test support to JUnit 5: our plan is to offer maximum
> >> > flexibility by providing the vintage engine (so that users can keep
> >> their
> >> > tests and migrate at their own pace).
> >> >
> >> > We can't upgrade to a milestone as our upgrade policy prevents that
> >> > (regardless of how stable this is and especially since backward
> >> > incompatible changes have been pushed to the latest milestone). So
> we're
> >> > kind of stuck.
> >> >
> >> > Would there be an appetite to backport those fixes and release a
> 2.22.2?
> >> >
> >> > Thanks,
> >> > S.
> >> >
> >> > [1] https://issues.apache.org/jira/browse/SUREFIRE-1614
> >> > [2]
> >> https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546
> >> >
> >>
> >
>

Re: Surefire maintenance release

[Stephane Nicoll]

Hey,

Can someone working on surefire confirm the interest of creating that
branch in the main repo and kick-off a release if a review is satisfactory?

Thanks!
S.


On Wed, Mar 13, 2019 at 4:09 PM Stephane Nicoll 
wrote:

> Hey,
>
> I've created a `2.22.x` branch based on the 2.22.1 tag and I've
> cherry-picked the issue we need to get proper support for the vintage
> engine[1]
>
> This 2.22.2-SNAPSHOT works for our purpose so I was wondering if more
> fixes could be backported and/or if someone would like to review those
> changes.
>
> Thanks,
> S.
>
>
> [1] https://github.com/snicoll/maven-surefire/tree/2.22.x
>
> On Wed, Feb 27, 2019 at 1:46 PM Tibor Digana 
> wrote:
>
>> Hi  Stephane,
>>
>> We are talking only about these two commits [1]?
>> Notice that 001e807 modifies file names to the verbose one which breaks
>> backwards compatibility and this should not forcibly (by default) happen
>> in
>> your version/branch.
>> Try to fork the project, make a local branch and then reset HEAD to [2],
>> i.e. git reset --hard 19006aa70f36705f399b8c105a16f636904f00f3
>> And then cherrypick both commits [1].
>> Make sure the order is correct but it won't be so straightforward. The
>> tests have to pass (mvn install -P run-its).
>>
>> [1]:
>>
>> https://github.com/apache/maven-surefire/commit/f517d349ede0e15229e3c48f45d10dabc72a3fc9
>>
>> https://github.com/apache/maven-surefire/commit/001e8075b8db7861aaefb5af4c256d919a9b2e7a
>>
>> [2]:
>>
>> https://github.com/apache/maven-surefire/commit/19006aa70f36705f399b8c105a16f636904f00f3
>>
>> Cheers
>> Tibor
>>
>> On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll <
>> stephane.nic...@gmail.com>
>> wrote:
>>
>> > Hi everyone,
>> >
>> > It's great to see the progress on Surefire 3.0 and I wanted to reach
>> out to
>> > discuss a practicable problem with the 2.x line. There are a number of
>> > fixes for JUnit 5 that are only available in the 3.x line that isn't GA
>> > yet. [1][2]
>> >
>> > Putting my Spring Boot hat for a min, this actually prevents us from
>> > upgrading our test support to JUnit 5: our plan is to offer maximum
>> > flexibility by providing the vintage engine (so that users can keep
>> their
>> > tests and migrate at their own pace).
>> >
>> > We can't upgrade to a milestone as our upgrade policy prevents that
>> > (regardless of how stable this is and especially since backward
>> > incompatible changes have been pushed to the latest milestone). So we're
>> > kind of stuck.
>> >
>> > Would there be an appetite to backport those fixes and release a 2.22.2?
>> >
>> > Thanks,
>> > S.
>> >
>> > [1] https://issues.apache.org/jira/browse/SUREFIRE-1614
>> > [2]
>> https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546
>> >
>>
>

Re: Surefire maintenance release

[Christian Stein]

Hi Stéphane,

due to JavaLand and other "business stuff", I'll plan to review your branch
early next week.
>From a first glimps, it looks good to me.

Cheers,
Christian


On Wed, Mar 20, 2019 at 9:26 AM Enrico Olivelli  wrote:

> +1
>
> Il mar 19 mar 2019, 22:29 Olivier Lamy  ha scritto:
>
> > Sounds good to have a maintenance release with this!
> >
> > On Thu, 14 Mar 2019 at 04:34, Enrico Olivelli 
> wrote:
> >
> > > Very good!
> > >
> > > Enrico
> > >
> > > Il mer 13 mar 2019, 16:09 Stephane Nicoll 
> ha
> > > scritto:
> > >
> > > > Hey,
> > > >
> > > > I've created a `2.22.x` branch based on the 2.22.1 tag and I've
> > > > cherry-picked the issue we need to get proper support for the vintage
> > > > engine[1]
> > > >
> > > > This 2.22.2-SNAPSHOT works for our purpose so I was wondering if more
> > > fixes
> > > > could be backported and/or if someone would like to review those
> > changes.
> > > >
> > > > Thanks,
> > > > S.
> > > >
> > > >
> > > > [1] https://github.com/snicoll/maven-surefire/tree/2.22.x
> > > >
> > > > On Wed, Feb 27, 2019 at 1:46 PM Tibor Digana  >
> > > > wrote:
> > > >
> > > > > Hi  Stephane,
> > > > >
> > > > > We are talking only about these two commits [1]?
> > > > > Notice that 001e807 modifies file names to the verbose one which
> > breaks
> > > > > backwards compatibility and this should not forcibly (by default)
> > > happen
> > > > in
> > > > > your version/branch.
> > > > > Try to fork the project, make a local branch and then reset HEAD to
> > > [2],
> > > > > i.e. git reset --hard 19006aa70f36705f399b8c105a16f636904f00f3
> > > > > And then cherrypick both commits [1].
> > > > > Make sure the order is correct but it won't be so straightforward.
> > The
> > > > > tests have to pass (mvn install -P run-its).
> > > > >
> > > > > [1]:
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-surefire/commit/f517d349ede0e15229e3c48f45d10dabc72a3fc9
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-surefire/commit/001e8075b8db7861aaefb5af4c256d919a9b2e7a
> > > > >
> > > > > [2]:
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-surefire/commit/19006aa70f36705f399b8c105a16f636904f00f3
> > > > >
> > > > > Cheers
> > > > > Tibor
> > > > >
> > > > > On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll <
> > > > stephane.nic...@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > Hi everyone,
> > > > > >
> > > > > > It's great to see the progress on Surefire 3.0 and I wanted to
> > reach
> > > > out
> > > > > to
> > > > > > discuss a practicable problem with the 2.x line. There are a
> number
> > > of
> > > > > > fixes for JUnit 5 that are only available in the 3.x line that
> > isn't
> > > GA
> > > > > > yet. [1][2]
> > > > > >
> > > > > > Putting my Spring Boot hat for a min, this actually prevents us
> > from
> > > > > > upgrading our test support to JUnit 5: our plan is to offer
> maximum
> > > > > > flexibility by providing the vintage engine (so that users can
> keep
> > > > their
> > > > > > tests and migrate at their own pace).
> > > > > >
> > > > > > We can't upgrade to a milestone as our upgrade policy prevents
> that
> > > > > > (regardless of how stable this is and especially since backward
> > > > > > incompatible changes have been pushed to the latest milestone).
> So
> > > > we're
> > > > > > kind of stuck.
> > > > > >
> > > > > > Would there be an appetite to backport those fixes and release a
> > > > 2.22.2?
> > > > > >
> > > > > > Thanks,
> > > > > > S.
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/SUREFIRE-1614
> > > > > > [2]
> > > > >
> > https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > Olivier Lamy
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >
>

Re: Surefire maintenance release

[Enrico Olivelli]

+1

Il mar 19 mar 2019, 22:29 Olivier Lamy  ha scritto:

> Sounds good to have a maintenance release with this!
>
> On Thu, 14 Mar 2019 at 04:34, Enrico Olivelli  wrote:
>
> > Very good!
> >
> > Enrico
> >
> > Il mer 13 mar 2019, 16:09 Stephane Nicoll  ha
> > scritto:
> >
> > > Hey,
> > >
> > > I've created a `2.22.x` branch based on the 2.22.1 tag and I've
> > > cherry-picked the issue we need to get proper support for the vintage
> > > engine[1]
> > >
> > > This 2.22.2-SNAPSHOT works for our purpose so I was wondering if more
> > fixes
> > > could be backported and/or if someone would like to review those
> changes.
> > >
> > > Thanks,
> > > S.
> > >
> > >
> > > [1] https://github.com/snicoll/maven-surefire/tree/2.22.x
> > >
> > > On Wed, Feb 27, 2019 at 1:46 PM Tibor Digana 
> > > wrote:
> > >
> > > > Hi  Stephane,
> > > >
> > > > We are talking only about these two commits [1]?
> > > > Notice that 001e807 modifies file names to the verbose one which
> breaks
> > > > backwards compatibility and this should not forcibly (by default)
> > happen
> > > in
> > > > your version/branch.
> > > > Try to fork the project, make a local branch and then reset HEAD to
> > [2],
> > > > i.e. git reset --hard 19006aa70f36705f399b8c105a16f636904f00f3
> > > > And then cherrypick both commits [1].
> > > > Make sure the order is correct but it won't be so straightforward.
> The
> > > > tests have to pass (mvn install -P run-its).
> > > >
> > > > [1]:
> > > >
> > > >
> > >
> >
> https://github.com/apache/maven-surefire/commit/f517d349ede0e15229e3c48f45d10dabc72a3fc9
> > > >
> > > >
> > >
> >
> https://github.com/apache/maven-surefire/commit/001e8075b8db7861aaefb5af4c256d919a9b2e7a
> > > >
> > > > [2]:
> > > >
> > > >
> > >
> >
> https://github.com/apache/maven-surefire/commit/19006aa70f36705f399b8c105a16f636904f00f3
> > > >
> > > > Cheers
> > > > Tibor
> > > >
> > > > On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll <
> > > stephane.nic...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Hi everyone,
> > > > >
> > > > > It's great to see the progress on Surefire 3.0 and I wanted to
> reach
> > > out
> > > > to
> > > > > discuss a practicable problem with the 2.x line. There are a number
> > of
> > > > > fixes for JUnit 5 that are only available in the 3.x line that
> isn't
> > GA
> > > > > yet. [1][2]
> > > > >
> > > > > Putting my Spring Boot hat for a min, this actually prevents us
> from
> > > > > upgrading our test support to JUnit 5: our plan is to offer maximum
> > > > > flexibility by providing the vintage engine (so that users can keep
> > > their
> > > > > tests and migrate at their own pace).
> > > > >
> > > > > We can't upgrade to a milestone as our upgrade policy prevents that
> > > > > (regardless of how stable this is and especially since backward
> > > > > incompatible changes have been pushed to the latest milestone). So
> > > we're
> > > > > kind of stuck.
> > > > >
> > > > > Would there be an appetite to backport those fixes and release a
> > > 2.22.2?
> > > > >
> > > > > Thanks,
> > > > > S.
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/SUREFIRE-1614
> > > > > [2]
> > > >
> https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546
> > > > >
> > > >
> > >
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Re: Surefire maintenance release

[Olivier Lamy]

Sounds good to have a maintenance release with this!

On Thu, 14 Mar 2019 at 04:34, Enrico Olivelli  wrote:

> Very good!
>
> Enrico
>
> Il mer 13 mar 2019, 16:09 Stephane Nicoll  ha
> scritto:
>
> > Hey,
> >
> > I've created a `2.22.x` branch based on the 2.22.1 tag and I've
> > cherry-picked the issue we need to get proper support for the vintage
> > engine[1]
> >
> > This 2.22.2-SNAPSHOT works for our purpose so I was wondering if more
> fixes
> > could be backported and/or if someone would like to review those changes.
> >
> > Thanks,
> > S.
> >
> >
> > [1] https://github.com/snicoll/maven-surefire/tree/2.22.x
> >
> > On Wed, Feb 27, 2019 at 1:46 PM Tibor Digana 
> > wrote:
> >
> > > Hi  Stephane,
> > >
> > > We are talking only about these two commits [1]?
> > > Notice that 001e807 modifies file names to the verbose one which breaks
> > > backwards compatibility and this should not forcibly (by default)
> happen
> > in
> > > your version/branch.
> > > Try to fork the project, make a local branch and then reset HEAD to
> [2],
> > > i.e. git reset --hard 19006aa70f36705f399b8c105a16f636904f00f3
> > > And then cherrypick both commits [1].
> > > Make sure the order is correct but it won't be so straightforward. The
> > > tests have to pass (mvn install -P run-its).
> > >
> > > [1]:
> > >
> > >
> >
> https://github.com/apache/maven-surefire/commit/f517d349ede0e15229e3c48f45d10dabc72a3fc9
> > >
> > >
> >
> https://github.com/apache/maven-surefire/commit/001e8075b8db7861aaefb5af4c256d919a9b2e7a
> > >
> > > [2]:
> > >
> > >
> >
> https://github.com/apache/maven-surefire/commit/19006aa70f36705f399b8c105a16f636904f00f3
> > >
> > > Cheers
> > > Tibor
> > >
> > > On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll <
> > stephane.nic...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > It's great to see the progress on Surefire 3.0 and I wanted to reach
> > out
> > > to
> > > > discuss a practicable problem with the 2.x line. There are a number
> of
> > > > fixes for JUnit 5 that are only available in the 3.x line that isn't
> GA
> > > > yet. [1][2]
> > > >
> > > > Putting my Spring Boot hat for a min, this actually prevents us from
> > > > upgrading our test support to JUnit 5: our plan is to offer maximum
> > > > flexibility by providing the vintage engine (so that users can keep
> > their
> > > > tests and migrate at their own pace).
> > > >
> > > > We can't upgrade to a milestone as our upgrade policy prevents that
> > > > (regardless of how stable this is and especially since backward
> > > > incompatible changes have been pushed to the latest milestone). So
> > we're
> > > > kind of stuck.
> > > >
> > > > Would there be an appetite to backport those fixes and release a
> > 2.22.2?
> > > >
> > > > Thanks,
> > > > S.
> > > >
> > > > [1] https://issues.apache.org/jira/browse/SUREFIRE-1614
> > > > [2]
> > > https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546
> > > >
> > >
> >
>


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

Re: Surefire maintenance release

[Enrico Olivelli]

Very good!

Enrico

Il mer 13 mar 2019, 16:09 Stephane Nicoll  ha
scritto:

> Hey,
>
> I've created a `2.22.x` branch based on the 2.22.1 tag and I've
> cherry-picked the issue we need to get proper support for the vintage
> engine[1]
>
> This 2.22.2-SNAPSHOT works for our purpose so I was wondering if more fixes
> could be backported and/or if someone would like to review those changes.
>
> Thanks,
> S.
>
>
> [1] https://github.com/snicoll/maven-surefire/tree/2.22.x
>
> On Wed, Feb 27, 2019 at 1:46 PM Tibor Digana 
> wrote:
>
> > Hi  Stephane,
> >
> > We are talking only about these two commits [1]?
> > Notice that 001e807 modifies file names to the verbose one which breaks
> > backwards compatibility and this should not forcibly (by default) happen
> in
> > your version/branch.
> > Try to fork the project, make a local branch and then reset HEAD to [2],
> > i.e. git reset --hard 19006aa70f36705f399b8c105a16f636904f00f3
> > And then cherrypick both commits [1].
> > Make sure the order is correct but it won't be so straightforward. The
> > tests have to pass (mvn install -P run-its).
> >
> > [1]:
> >
> >
> https://github.com/apache/maven-surefire/commit/f517d349ede0e15229e3c48f45d10dabc72a3fc9
> >
> >
> https://github.com/apache/maven-surefire/commit/001e8075b8db7861aaefb5af4c256d919a9b2e7a
> >
> > [2]:
> >
> >
> https://github.com/apache/maven-surefire/commit/19006aa70f36705f399b8c105a16f636904f00f3
> >
> > Cheers
> > Tibor
> >
> > On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll <
> stephane.nic...@gmail.com
> > >
> > wrote:
> >
> > > Hi everyone,
> > >
> > > It's great to see the progress on Surefire 3.0 and I wanted to reach
> out
> > to
> > > discuss a practicable problem with the 2.x line. There are a number of
> > > fixes for JUnit 5 that are only available in the 3.x line that isn't GA
> > > yet. [1][2]
> > >
> > > Putting my Spring Boot hat for a min, this actually prevents us from
> > > upgrading our test support to JUnit 5: our plan is to offer maximum
> > > flexibility by providing the vintage engine (so that users can keep
> their
> > > tests and migrate at their own pace).
> > >
> > > We can't upgrade to a milestone as our upgrade policy prevents that
> > > (regardless of how stable this is and especially since backward
> > > incompatible changes have been pushed to the latest milestone). So
> we're
> > > kind of stuck.
> > >
> > > Would there be an appetite to backport those fixes and release a
> 2.22.2?
> > >
> > > Thanks,
> > > S.
> > >
> > > [1] https://issues.apache.org/jira/browse/SUREFIRE-1614
> > > [2]
> > https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546
> > >
> >
>

Re: Surefire maintenance release

[Stephane Nicoll]

Hey,

I've created a `2.22.x` branch based on the 2.22.1 tag and I've
cherry-picked the issue we need to get proper support for the vintage
engine[1]

This 2.22.2-SNAPSHOT works for our purpose so I was wondering if more fixes
could be backported and/or if someone would like to review those changes.

Thanks,
S.


[1] https://github.com/snicoll/maven-surefire/tree/2.22.x

On Wed, Feb 27, 2019 at 1:46 PM Tibor Digana  wrote:

> Hi  Stephane,
>
> We are talking only about these two commits [1]?
> Notice that 001e807 modifies file names to the verbose one which breaks
> backwards compatibility and this should not forcibly (by default) happen in
> your version/branch.
> Try to fork the project, make a local branch and then reset HEAD to [2],
> i.e. git reset --hard 19006aa70f36705f399b8c105a16f636904f00f3
> And then cherrypick both commits [1].
> Make sure the order is correct but it won't be so straightforward. The
> tests have to pass (mvn install -P run-its).
>
> [1]:
>
> https://github.com/apache/maven-surefire/commit/f517d349ede0e15229e3c48f45d10dabc72a3fc9
>
> https://github.com/apache/maven-surefire/commit/001e8075b8db7861aaefb5af4c256d919a9b2e7a
>
> [2]:
>
> https://github.com/apache/maven-surefire/commit/19006aa70f36705f399b8c105a16f636904f00f3
>
> Cheers
> Tibor
>
> On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll  >
> wrote:
>
> > Hi everyone,
> >
> > It's great to see the progress on Surefire 3.0 and I wanted to reach out
> to
> > discuss a practicable problem with the 2.x line. There are a number of
> > fixes for JUnit 5 that are only available in the 3.x line that isn't GA
> > yet. [1][2]
> >
> > Putting my Spring Boot hat for a min, this actually prevents us from
> > upgrading our test support to JUnit 5: our plan is to offer maximum
> > flexibility by providing the vintage engine (so that users can keep their
> > tests and migrate at their own pace).
> >
> > We can't upgrade to a milestone as our upgrade policy prevents that
> > (regardless of how stable this is and especially since backward
> > incompatible changes have been pushed to the latest milestone). So we're
> > kind of stuck.
> >
> > Would there be an appetite to backport those fixes and release a 2.22.2?
> >
> > Thanks,
> > S.
> >
> > [1] https://issues.apache.org/jira/browse/SUREFIRE-1614
> > [2]
> https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546
> >
>

Re: Surefire maintenance release

[Christian Stein]

Hi all,

here are my 0.02 € on the two issues/PRs that went into Surefire 3.x
already.

*SUREFIRE-1546  "JUnit 5 display names"*

Both, supporting "@DisplayName" and therefore also backporting
https://issues.apache.org/jira/browse/SUREFIRE-1546 to the 2.x branch makes
almost *no* sense to me. Surefire (and every other testing tool out there
using
the XML format defined by Ant) suffers the same limitations as the JUnit
Platform
ConsoleLauncher: display names may be used on the console when logging
test run progress or results to the user in a human-friendly manner - but
display
names in XML / text reports as (unique !) identifiers will either break due
to file
system constraints or cause downstream processes choke. See this answer
for some more details [1].

I support having this feature as an optional feature, as suggested by Tibor.
Users who know what they do, may enable it at their own risk. Further work
should be directed to [2] "Define a standard for test reports" -- everybody
feel
invited to contribute!

*SUREFIRE-1614"**JUnit's Vintage Engine* *corrupts Surefire's STDOUT*
*"  *

Changes made in [3] are not numerous. Methinks, if there was a Surefire
2.22.x
branch, then commit [4] could be cherry-picked to it and Surefire 2.22.2
released
shortly after that.

Tibor, on which commit would such a bug-fix branched be based on? [5] or
later
to also include Java 11 support?

Cheers,
Christian

[1]
https://issues.apache.org/jira/browse/SUREFIRE-1546?focusedCommentId=16758470=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16758470
[2] https://github.com/ota4j-team/opentest4j/issues/9
[3] https://github.com/apache/maven-surefire/pull/209/files
[4]
https://github.com/apache/maven-surefire/commit/f517d349ede0e15229e3c48f45d10dabc72a3fc9
[5]
https://github.com/apache/maven-surefire/commit/19006aa70f36705f399b8c105a16f636904f00f3

On Wed, Feb 27, 2019 at 1:46 PM Tibor Digana  wrote:

> Hi  Stephane,
>
> We are talking only about these two commits [1]?
> Notice that 001e807 modifies file names to the verbose one which breaks
> backwards compatibility and this should not forcibly (by default) happen in
> your version/branch.
> Try to fork the project, make a local branch and then reset HEAD to [2],
> i.e. git reset --hard 19006aa70f36705f399b8c105a16f636904f00f3
> And then cherrypick both commits [1].
> Make sure the order is correct but it won't be so straightforward. The
> tests have to pass (mvn install -P run-its).
>
> [1]:
>
> https://github.com/apache/maven-surefire/commit/f517d349ede0e15229e3c48f45d10dabc72a3fc9
>
> https://github.com/apache/maven-surefire/commit/001e8075b8db7861aaefb5af4c256d919a9b2e7a
>
> [2]:
>
> https://github.com/apache/maven-surefire/commit/19006aa70f36705f399b8c105a16f636904f00f3
>
> Cheers
> Tibor
>
> On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll  >
> wrote:
>
> > Hi everyone,
> >
> > It's great to see the progress on Surefire 3.0 and I wanted to reach out
> to
> > discuss a practicable problem with the 2.x line. There are a number of
> > fixes for JUnit 5 that are only available in the 3.x line that isn't GA
> > yet. [1][2]
> >
> > Putting my Spring Boot hat for a min, this actually prevents us from
> > upgrading our test support to JUnit 5: our plan is to offer maximum
> > flexibility by providing the vintage engine (so that users can keep their
> > tests and migrate at their own pace).
> >
> > We can't upgrade to a milestone as our upgrade policy prevents that
> > (regardless of how stable this is and especially since backward
> > incompatible changes have been pushed to the latest milestone). So we're
> > kind of stuck.
> >
> > Would there be an appetite to backport those fixes and release a 2.22.2?
> >
> > Thanks,
> > S.
> >
> > [1] https://issues.apache.org/jira/browse/SUREFIRE-1614
> > [2]
> https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546
> >
>

Re: Surefire maintenance release

[Tibor Digana]

Hi  Stephane,

We are talking only about these two commits [1]?
Notice that 001e807 modifies file names to the verbose one which breaks
backwards compatibility and this should not forcibly (by default) happen in
your version/branch.
Try to fork the project, make a local branch and then reset HEAD to [2],
i.e. git reset --hard 19006aa70f36705f399b8c105a16f636904f00f3
And then cherrypick both commits [1].
Make sure the order is correct but it won't be so straightforward. The
tests have to pass (mvn install -P run-its).

[1]:
https://github.com/apache/maven-surefire/commit/f517d349ede0e15229e3c48f45d10dabc72a3fc9
https://github.com/apache/maven-surefire/commit/001e8075b8db7861aaefb5af4c256d919a9b2e7a

[2]:
https://github.com/apache/maven-surefire/commit/19006aa70f36705f399b8c105a16f636904f00f3

Cheers
Tibor

On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll 
wrote:

> Hi everyone,
>
> It's great to see the progress on Surefire 3.0 and I wanted to reach out to
> discuss a practicable problem with the 2.x line. There are a number of
> fixes for JUnit 5 that are only available in the 3.x line that isn't GA
> yet. [1][2]
>
> Putting my Spring Boot hat for a min, this actually prevents us from
> upgrading our test support to JUnit 5: our plan is to offer maximum
> flexibility by providing the vintage engine (so that users can keep their
> tests and migrate at their own pace).
>
> We can't upgrade to a milestone as our upgrade policy prevents that
> (regardless of how stable this is and especially since backward
> incompatible changes have been pushed to the latest milestone). So we're
> kind of stuck.
>
> Would there be an appetite to backport those fixes and release a 2.22.2?
>
> Thanks,
> S.
>
> [1] https://issues.apache.org/jira/browse/SUREFIRE-1614
> [2] https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546
>

Re: Surefire maintenance release

[Olivier Lamy]

Hi
Using slack is a good idea for discussion.
But bear mind @ASF all decisions must appear on a mailing list or in a jira
ticket.
Interesting blog entry regarding this topic "If it didn’t happen on the
mailing list, it didn’t happen." http://theapacheway.com/on-list/
think about timezone or people availability and btw this slack is only
for @apache user  etc...



On Wed, 27 Feb 2019 at 04:01, Tibor Digana  wrote:

> Stephane,
> I have been quite busy with other JUnit5 work - SUREFIRE-1585.
> Can you join us in the chat on Slack "the-asf.slack.com"?
> You will find the Channel named "surefire".
> Ping us as soon as you are ready and we will find some way.
> I am glad!
>
> Cheers
> Tibor
>
> On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll  >
> wrote:
>
> > Hi everyone,
> >
> > It's great to see the progress on Surefire 3.0 and I wanted to reach out
> to
> > discuss a practicable problem with the 2.x line. There are a number of
> > fixes for JUnit 5 that are only available in the 3.x line that isn't GA
> > yet. [1][2]
> >
> > Putting my Spring Boot hat for a min, this actually prevents us from
> > upgrading our test support to JUnit 5: our plan is to offer maximum
> > flexibility by providing the vintage engine (so that users can keep their
> > tests and migrate at their own pace).
> >
> > We can't upgrade to a milestone as our upgrade policy prevents that
> > (regardless of how stable this is and especially since backward
> > incompatible changes have been pushed to the latest milestone). So we're
> > kind of stuck.
> >
> > Would there be an appetite to backport those fixes and release a 2.22.2?
> >
> > Thanks,
> > S.
> >
> > [1] https://issues.apache.org/jira/browse/SUREFIRE-1614
> > [2]
> https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546
> >
>


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

Re: Surefire maintenance release

[Tibor Digana]

Stephane,
I have been quite busy with other JUnit5 work - SUREFIRE-1585.
Can you join us in the chat on Slack "the-asf.slack.com"?
You will find the Channel named "surefire".
Ping us as soon as you are ready and we will find some way.
I am glad!

Cheers
Tibor

On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll 
wrote:

> Hi everyone,
>
> It's great to see the progress on Surefire 3.0 and I wanted to reach out to
> discuss a practicable problem with the 2.x line. There are a number of
> fixes for JUnit 5 that are only available in the 3.x line that isn't GA
> yet. [1][2]
>
> Putting my Spring Boot hat for a min, this actually prevents us from
> upgrading our test support to JUnit 5: our plan is to offer maximum
> flexibility by providing the vintage engine (so that users can keep their
> tests and migrate at their own pace).
>
> We can't upgrade to a milestone as our upgrade policy prevents that
> (regardless of how stable this is and especially since backward
> incompatible changes have been pushed to the latest milestone). So we're
> kind of stuck.
>
> Would there be an appetite to backport those fixes and release a 2.22.2?
>
> Thanks,
> S.
>
> [1] https://issues.apache.org/jira/browse/SUREFIRE-1614
> [2] https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546
>

Re: Surefire maintenance release

[Stephane Nicoll]

Thanks Robert.

To emphasis on the goal, we'd like to get a GA release of surefire that
fully supports JUnit 5 (including the use of the vintage engine) and we'd
like to see if it would be possible to backport the two fixes I've
mentioned. If there is an appetite for that, we're happy to help and test
snapshos and I believe the JUnit team would also be willing to help as they
have contributed numerous PRs in the past.

If a fix cannot be enabled by default in a maintenance release, we'd like
to understand why and how we can mitigate this for our users.

Thank you,
S.


On Mon, Feb 25, 2019 at 3:01 PM Robert Scholte  wrote:

> Let me guide this discussion a bit, because I see tends to go to the
> negative side, whereas I'd like to see this as an open and fair discussion.
>
> It is not up to us to decide what any company/organization policy is
> regarding versions.
> Putting yourself in the position of Pivotal it makes sense to rely only
> on
> GA versions.
> There must be a reason why Surefire is released with milestones: things
> might break and maybe for valid reasons.
> We should prevent the situation where contributors see a milestone and
> "kindly" update it because there's a non-milestone version available,
> whereas one of the next surefire milestone would decide to break
> backwards
> compatibility. So this is not just about looking back and knowing that
> the
> latest milestone still works like 2.22.1, but also about the upcoming
> versions!
>
> To me the question of Stephane is fair: is it possible to backport
> SUREFIRE-1614 and SUREFIRE-1546? In other words: do these fixes depend on
> 3.0.0 specific changes or not? If so, then there's no reason to continue.
> Otherwise is it possible (with or without help of Pivotal or other
> volunteers) to provide patches which can be applied and released?
>
> Stephane could have picked this up on his own, bypassing the main
> maintainers of surefire, but he didn't. Instead he's asking for
> cooperation.
>
> So try to keep the discussion polite and let's work together toward
> solutions.
>
> thanks,
> Robert
>
> On Mon, 25 Feb 2019 12:53:04 +0100, Tibor Digana 
>
> wrote:
>
> > Sorry, in normal circumstances projects release BOM with
> > dependencyManagement but not the pluginManagement.
> > We did not break current users and so we split the entire work into
> > multiple stages. The naming convention really is not a problem as you can
> > see and Stephane confirmed it.
> > So we made welcome compromises on our side in ASF and now your steps in
> > Spring should be to make compromise in your internal policies.
> >
> > Cheers
> > Tibor
> >
> > On Mon, Feb 25, 2019 at 11:44 AM Stephane Nicoll
> > 
> > wrote:
> >
> >> Thanks for the reply. See my feedback below
> >>
> >> On Mon, Feb 25, 2019 at 11:20 AM Tibor Digana 
> >> wrote:
> >>
> >> > Stephane, the problem is with Spring upgrade policy as I have
> >> understood.
> >> >
> >> > What about releasing RC4 for you?
> >> >
> >>
> >> It does not matter how you call it. We don't want to be in a position
> >> where
> >> our users get plugin management for a given version of surefire that:
> >>
> >> 1. is not GA
> >> 2. subsequent milestone/RC/release will break backward compatibility
> >>
> >>
> >>
> >> > Do you really need to have SUREFIRE-1546 done? We do not want to
> >> enable
> >> it
> >> > implicitly as it is done in master right now, and therefore M4 needs
> >> to
> >> > take more time to enable this feature via configuration.
> >> >
> >>
> >> I think we do.
> >>
> >> A minor release of Spring Boot cannot require users to write their tests
> >> using the JUnit 5 API as it would be a breaking change for every test
> >> they’ve written using JUnit 4. On the other hand, we know that users
> >> want
> >> to be able to use JUnit 5 and we’re holding them back at the moment.
> >>
> >> The way the JUnit team has dealt with the migration is the use of the
> >> vintage engine that we would provide by default. Users that have
> >> migrated
> >> their tests can exclude the vintage engine while users that are in the
> >> process of migrating can benefit from a setup where they can start
> >> migrating while keeping some of their tests unchanged.
> >>
> >> We need surefire to support that scenario and the 2.x line does not.
> >>
> >>
> >> >
> >> > I see that the policy is against itself. If you concentrate only on
> >> > policies with project dependencies, you won't break anything.
> >> > We made a big investment (SUREFIRE-1614, ...) to not to break current
> >> > users. So please let us continue our work and let you and yourself use
> >> > 3.0.0-M3 and continue whatever it means with Spring policies.Our
> plan
> >> is
> >> to
> >> > not to break backwards compatibility till 3.0.0-M5.
> >> >
> >>
> >> As I've indicated, we cannot upgrade to a version and then be stuck on
> >> milestones because a later one introduces backward incompatible changes.
> >>
> >>
> >> >
> >> > There is reason that you use Surefire in your project 

Re: Surefire maintenance release

[Robert Scholte]

Let me guide this discussion a bit, because I see tends to go to the  
negative side, whereas I'd like to see this as an open and fair discussion.


It is not up to us to decide what any company/organization policy is  
regarding versions.
Putting yourself in the position of Pivotal it makes sense to rely only on  
GA versions.
There must be a reason why Surefire is released with milestones: things  
might break and maybe for valid reasons.
We should prevent the situation where contributors see a milestone and  
"kindly" update it because there's a non-milestone version available,  
whereas one of the next surefire milestone would decide to break backwards  
compatibility. So this is not just about looking back and knowing that the  
latest milestone still works like 2.22.1, but also about the upcoming  
versions!


To me the question of Stephane is fair: is it possible to backport  
SUREFIRE-1614 and SUREFIRE-1546? In other words: do these fixes depend on  
3.0.0 specific changes or not? If so, then there's no reason to continue.  
Otherwise is it possible (with or without help of Pivotal or other  
volunteers) to provide patches which can be applied and released?


Stephane could have picked this up on his own, bypassing the main  
maintainers of surefire, but he didn't. Instead he's asking for  
cooperation.


So try to keep the discussion polite and let's work together toward  
solutions.


thanks,
Robert

On Mon, 25 Feb 2019 12:53:04 +0100, Tibor Digana   
wrote:



Sorry, in normal circumstances projects release BOM with
dependencyManagement but not the pluginManagement.
We did not break current users and so we split the entire work into
multiple stages. The naming convention really is not a problem as you can
see and Stephane confirmed it.
So we made welcome compromises on our side in ASF and now your steps in
Spring should be to make compromise in your internal policies.

Cheers
Tibor

On Mon, Feb 25, 2019 at 11:44 AM Stephane Nicoll  


wrote:


Thanks for the reply. See my feedback below

On Mon, Feb 25, 2019 at 11:20 AM Tibor Digana 
wrote:

> Stephane, the problem is with Spring upgrade policy as I have  
understood.

>
> What about releasing RC4 for you?
>

It does not matter how you call it. We don't want to be in a position  
where

our users get plugin management for a given version of surefire that:

1. is not GA
2. subsequent milestone/RC/release will break backward compatibility



> Do you really need to have SUREFIRE-1546 done? We do not want to  
enable

it
> implicitly as it is done in master right now, and therefore M4 needs  
to

> take more time to enable this feature via configuration.
>

I think we do.

A minor release of Spring Boot cannot require users to write their tests
using the JUnit 5 API as it would be a breaking change for every test
they’ve written using JUnit 4. On the other hand, we know that users  
want

to be able to use JUnit 5 and we’re holding them back at the moment.

The way the JUnit team has dealt with the migration is the use of the
vintage engine that we would provide by default. Users that have  
migrated

their tests can exclude the vintage engine while users that are in the
process of migrating can benefit from a setup where they can start
migrating while keeping some of their tests unchanged.

We need surefire to support that scenario and the 2.x line does not.


>
> I see that the policy is against itself. If you concentrate only on
> policies with project dependencies, you won't break anything.
> We made a big investment (SUREFIRE-1614, ...) to not to break current
> users. So please let us continue our work and let you and yourself use
> 3.0.0-M3 and continue whatever it means with Spring policies.Our plan  
is

to
> not to break backwards compatibility till 3.0.0-M5.
>

As I've indicated, we cannot upgrade to a version and then be stuck on
milestones because a later one introduces backward incompatible changes.


>
> There is reason that you use Surefire in your project and provide us  
with

> feedback. We can always release milestones or RCs (which don't have
> different meaning for me).
>

To be fair, we use surefire because Spring Boot supports Maven (as it
should). JUnit 5 was released 18 months ago so a full support in the
current GA would be very much appreciated.



>
> Meanwhile, please check it out with version 3.0.0-M4-SNAPSHOT from
>
>
https://repository.apache.org/content/groups/snapshots/org/apache/maven/plugins/maven-surefire-plugin/
> (plugin repository) and let us know with the feedback.
>
> Is RC4 legal for your policies?
>

No it isn't. The name is not the problem by the way as I've hopefully
indicated above.

Thanks,
S.




>
> Cheers
> Tibor
>
>
> On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll <
stephane.nic...@gmail.com
> >
> wrote:
>
> > Hi everyone,
> >
> > It's great to see the progress on Surefire 3.0 and I wanted to reach
out
> to
> > discuss a practicable problem with the 2.x line. There are a number  
of
> > fixes 

Re: Surefire maintenance release

[Tibor Digana]

Sorry, in normal circumstances projects release BOM with
dependencyManagement but not the pluginManagement.
We did not break current users and so we split the entire work into
multiple stages. The naming convention really is not a problem as you can
see and Stephane confirmed it.
So we made welcome compromises on our side in ASF and now your steps in
Spring should be to make compromise in your internal policies.

Cheers
Tibor

On Mon, Feb 25, 2019 at 11:44 AM Stephane Nicoll 
wrote:

> Thanks for the reply. See my feedback below
>
> On Mon, Feb 25, 2019 at 11:20 AM Tibor Digana 
> wrote:
>
> > Stephane, the problem is with Spring upgrade policy as I have understood.
> >
> > What about releasing RC4 for you?
> >
>
> It does not matter how you call it. We don't want to be in a position where
> our users get plugin management for a given version of surefire that:
>
> 1. is not GA
> 2. subsequent milestone/RC/release will break backward compatibility
>
>
>
> > Do you really need to have SUREFIRE-1546 done? We do not want to enable
> it
> > implicitly as it is done in master right now, and therefore M4 needs to
> > take more time to enable this feature via configuration.
> >
>
> I think we do.
>
> A minor release of Spring Boot cannot require users to write their tests
> using the JUnit 5 API as it would be a breaking change for every test
> they’ve written using JUnit 4. On the other hand, we know that users want
> to be able to use JUnit 5 and we’re holding them back at the moment.
>
> The way the JUnit team has dealt with the migration is the use of the
> vintage engine that we would provide by default. Users that have migrated
> their tests can exclude the vintage engine while users that are in the
> process of migrating can benefit from a setup where they can start
> migrating while keeping some of their tests unchanged.
>
> We need surefire to support that scenario and the 2.x line does not.
>
>
> >
> > I see that the policy is against itself. If you concentrate only on
> > policies with project dependencies, you won't break anything.
> > We made a big investment (SUREFIRE-1614, ...) to not to break current
> > users. So please let us continue our work and let you and yourself use
> > 3.0.0-M3 and continue whatever it means with Spring policies.Our plan is
> to
> > not to break backwards compatibility till 3.0.0-M5.
> >
>
> As I've indicated, we cannot upgrade to a version and then be stuck on
> milestones because a later one introduces backward incompatible changes.
>
>
> >
> > There is reason that you use Surefire in your project and provide us with
> > feedback. We can always release milestones or RCs (which don't have
> > different meaning for me).
> >
>
> To be fair, we use surefire because Spring Boot supports Maven (as it
> should). JUnit 5 was released 18 months ago so a full support in the
> current GA would be very much appreciated.
>
>
>
> >
> > Meanwhile, please check it out with version 3.0.0-M4-SNAPSHOT from
> >
> >
> https://repository.apache.org/content/groups/snapshots/org/apache/maven/plugins/maven-surefire-plugin/
> > (plugin repository) and let us know with the feedback.
> >
> > Is RC4 legal for your policies?
> >
>
> No it isn't. The name is not the problem by the way as I've hopefully
> indicated above.
>
> Thanks,
> S.
>
>
>
>
> >
> > Cheers
> > Tibor
> >
> >
> > On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll <
> stephane.nic...@gmail.com
> > >
> > wrote:
> >
> > > Hi everyone,
> > >
> > > It's great to see the progress on Surefire 3.0 and I wanted to reach
> out
> > to
> > > discuss a practicable problem with the 2.x line. There are a number of
> > > fixes for JUnit 5 that are only available in the 3.x line that isn't GA
> > > yet. [1][2]
> > >
> > > Putting my Spring Boot hat for a min, this actually prevents us from
> > > upgrading our test support to JUnit 5: our plan is to offer maximum
> > > flexibility by providing the vintage engine (so that users can keep
> their
> > > tests and migrate at their own pace).
> > >
> > > We can't upgrade to a milestone as our upgrade policy prevents that
> > > (regardless of how stable this is and especially since backward
> > > incompatible changes have been pushed to the latest milestone). So
> we're
> > > kind of stuck.
> > >
> > > Would there be an appetite to backport those fixes and release a
> 2.22.2?
> > >
> > > Thanks,
> > > S.
> > >
> > > [1] https://issues.apache.org/jira/browse/SUREFIRE-1614
> > > [2]
> > https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546
> > >
> >
>

Re: Surefire maintenance release

[Stephane Nicoll]

Thanks for the reply. See my feedback below

On Mon, Feb 25, 2019 at 11:20 AM Tibor Digana 
wrote:

> Stephane, the problem is with Spring upgrade policy as I have understood.
>
> What about releasing RC4 for you?
>

It does not matter how you call it. We don't want to be in a position where
our users get plugin management for a given version of surefire that:

1. is not GA
2. subsequent milestone/RC/release will break backward compatibility



> Do you really need to have SUREFIRE-1546 done? We do not want to enable it
> implicitly as it is done in master right now, and therefore M4 needs to
> take more time to enable this feature via configuration.
>

I think we do.

A minor release of Spring Boot cannot require users to write their tests
using the JUnit 5 API as it would be a breaking change for every test
they’ve written using JUnit 4. On the other hand, we know that users want
to be able to use JUnit 5 and we’re holding them back at the moment.

The way the JUnit team has dealt with the migration is the use of the
vintage engine that we would provide by default. Users that have migrated
their tests can exclude the vintage engine while users that are in the
process of migrating can benefit from a setup where they can start
migrating while keeping some of their tests unchanged.

We need surefire to support that scenario and the 2.x line does not.


>
> I see that the policy is against itself. If you concentrate only on
> policies with project dependencies, you won't break anything.
> We made a big investment (SUREFIRE-1614, ...) to not to break current
> users. So please let us continue our work and let you and yourself use
> 3.0.0-M3 and continue whatever it means with Spring policies.Our plan is to
> not to break backwards compatibility till 3.0.0-M5.
>

As I've indicated, we cannot upgrade to a version and then be stuck on
milestones because a later one introduces backward incompatible changes.


>
> There is reason that you use Surefire in your project and provide us with
> feedback. We can always release milestones or RCs (which don't have
> different meaning for me).
>

To be fair, we use surefire because Spring Boot supports Maven (as it
should). JUnit 5 was released 18 months ago so a full support in the
current GA would be very much appreciated.



>
> Meanwhile, please check it out with version 3.0.0-M4-SNAPSHOT from
>
> https://repository.apache.org/content/groups/snapshots/org/apache/maven/plugins/maven-surefire-plugin/
> (plugin repository) and let us know with the feedback.
>
> Is RC4 legal for your policies?
>

No it isn't. The name is not the problem by the way as I've hopefully
indicated above.

Thanks,
S.




>
> Cheers
> Tibor
>
>
> On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll  >
> wrote:
>
> > Hi everyone,
> >
> > It's great to see the progress on Surefire 3.0 and I wanted to reach out
> to
> > discuss a practicable problem with the 2.x line. There are a number of
> > fixes for JUnit 5 that are only available in the 3.x line that isn't GA
> > yet. [1][2]
> >
> > Putting my Spring Boot hat for a min, this actually prevents us from
> > upgrading our test support to JUnit 5: our plan is to offer maximum
> > flexibility by providing the vintage engine (so that users can keep their
> > tests and migrate at their own pace).
> >
> > We can't upgrade to a milestone as our upgrade policy prevents that
> > (regardless of how stable this is and especially since backward
> > incompatible changes have been pushed to the latest milestone). So we're
> > kind of stuck.
> >
> > Would there be an appetite to backport those fixes and release a 2.22.2?
> >
> > Thanks,
> > S.
> >
> > [1] https://issues.apache.org/jira/browse/SUREFIRE-1614
> > [2]
> https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546
> >
>

Re: Surefire maintenance release

[Tibor Digana]

Stephane, the problem is with Spring upgrade policy as I have understood.

What about releasing RC4 for you?
Do you really need to have SUREFIRE-1546 done? We do not want to enable it
implicitly as it is done in master right now, and therefore M4 needs to
take more time to enable this feature via configuration.

I see that the policy is against itself. If you concentrate only on
policies with project dependencies, you won't break anything.
We made a big investment (SUREFIRE-1614, ...) to not to break current
users. So please let us continue our work and let you and yourself use
3.0.0-M3 and continue whatever it means with Spring policies.Our plan is to
not to break backwards compatibility till 3.0.0-M5.

There is reason that you use Surefire in your project and provide us with
feedback. We can always release milestones or RCs (which don't have
different meaning for me).

Meanwhile, please check it out with version 3.0.0-M4-SNAPSHOT from
https://repository.apache.org/content/groups/snapshots/org/apache/maven/plugins/maven-surefire-plugin/
(plugin repository) and let us know with the feedback.

Is RC4 legal for your policies?

Cheers
Tibor


On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll 
wrote:

> Hi everyone,
>
> It's great to see the progress on Surefire 3.0 and I wanted to reach out to
> discuss a practicable problem with the 2.x line. There are a number of
> fixes for JUnit 5 that are only available in the 3.x line that isn't GA
> yet. [1][2]
>
> Putting my Spring Boot hat for a min, this actually prevents us from
> upgrading our test support to JUnit 5: our plan is to offer maximum
> flexibility by providing the vintage engine (so that users can keep their
> tests and migrate at their own pace).
>
> We can't upgrade to a milestone as our upgrade policy prevents that
> (regardless of how stable this is and especially since backward
> incompatible changes have been pushed to the latest milestone). So we're
> kind of stuck.
>
> Would there be an appetite to backport those fixes and release a 2.22.2?
>
> Thanks,
> S.
>
> [1] https://issues.apache.org/jira/browse/SUREFIRE-1614
> [2] https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546
>

Surefire maintenance release

[Stephane Nicoll]

Hi everyone,

It's great to see the progress on Surefire 3.0 and I wanted to reach out to
discuss a practicable problem with the 2.x line. There are a number of
fixes for JUnit 5 that are only available in the 3.x line that isn't GA
yet. [1][2]

Putting my Spring Boot hat for a min, this actually prevents us from
upgrading our test support to JUnit 5: our plan is to offer maximum
flexibility by providing the vintage engine (so that users can keep their
tests and migrate at their own pace).

We can't upgrade to a milestone as our upgrade policy prevents that
(regardless of how stable this is and especially since backward
incompatible changes have been pushed to the latest milestone). So we're
kind of stuck.

Would there be an appetite to backport those fixes and release a 2.22.2?

Thanks,
S.

[1] https://issues.apache.org/jira/browse/SUREFIRE-1614
[2] https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546