You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Stephane Nicoll <st...@gmail.com> on 2019/03/13 15:09:25 UTC
Re: Surefire maintenance release
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 <ti...@apache.org> 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.nicoll@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
Posted by Tibor Digana <ti...@apache.org>.
I'll check the diff.
On Mon, Mar 25, 2019 at 3:38 PM Stephane Nicoll <st...@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.nicoll@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 <ti...@apache.org>
> > 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.nicoll@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
Posted by Christian Stein <so...@gmail.com>.
On Wed, Mar 27, 2019 at 6:14 PM Enrico Olivelli <eo...@gmail.com> wrote:
> Il mer 27 mar 2019, 18:10 Tibor Digana <ti...@apache.org> ha
> scritto:
>
> > Enrico, what i maintenance release for you, 2.22.2-M1?
> >
>
> 2.22.2 without suffix
>
>
This.
Re: Surefire maintenance release
Posted by Enrico Olivelli <eo...@gmail.com>.
Il giorno ven 26 apr 2019 alle ore 15:59 Stephane Nicoll
<st...@gmail.com> 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 <eo...@gmail.com>
> 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
> > <eo...@gmail.com> ha scritto:
> > >
> > > Staging the artifact now.
> > > It will take the whole day I guess
> > >
> > > Enrico
> > >
> > > Il mer 24 apr 2019, 13:21 Enrico Olivelli <eo...@gmail.com> ha
> > scritto:
> > >>
> > >> Il giorno mer 24 apr 2019 alle ore 12:30 Tibor Digana
> > >> <ti...@apache.org> 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 <eo...@gmail.com>
> > 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 <so...@gmail.com> ha
> > scritto:
> > >> > >
> > >> > > > On Thu, Apr 11, 2019 at 8:09 AM Enrico Olivelli <
> > eolivelli@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Surefire maintenance release
Posted by Stephane Nicoll <st...@gmail.com>.
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 <eo...@gmail.com>
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
> <eo...@gmail.com> ha scritto:
> >
> > Staging the artifact now.
> > It will take the whole day I guess
> >
> > Enrico
> >
> > Il mer 24 apr 2019, 13:21 Enrico Olivelli <eo...@gmail.com> ha
> scritto:
> >>
> >> Il giorno mer 24 apr 2019 alle ore 12:30 Tibor Digana
> >> <ti...@apache.org> 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 <eo...@gmail.com>
> 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 <so...@gmail.com> ha
> scritto:
> >> > >
> >> > > > On Thu, Apr 11, 2019 at 8:09 AM Enrico Olivelli <
> eolivelli@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
Posted by Benedikt Ritter <br...@apache.org>.
Am Do., 25. Apr. 2019 um 22:08 Uhr schrieb Enrico Olivelli <
eolivelli@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
> <eo...@gmail.com> ha scritto:
> >
> > Staging the artifact now.
> > It will take the whole day I guess
> >
> > Enrico
> >
> > Il mer 24 apr 2019, 13:21 Enrico Olivelli <eo...@gmail.com> ha
> scritto:
> >>
> >> Il giorno mer 24 apr 2019 alle ore 12:30 Tibor Digana
> >> <ti...@apache.org> 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 <eo...@gmail.com>
> 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 <so...@gmail.com> ha
> scritto:
> >> > >
> >> > > > On Thu, Apr 11, 2019 at 8:09 AM Enrico Olivelli <
> eolivelli@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Surefire maintenance release
Posted by Enrico Olivelli <eo...@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
Enrico
Il giorno gio 25 apr 2019 alle ore 10:25 Enrico Olivelli
<eo...@gmail.com> ha scritto:
>
> Staging the artifact now.
> It will take the whole day I guess
>
> Enrico
>
> Il mer 24 apr 2019, 13:21 Enrico Olivelli <eo...@gmail.com> ha scritto:
>>
>> Il giorno mer 24 apr 2019 alle ore 12:30 Tibor Digana
>> <ti...@apache.org> 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 <eo...@gmail.com> 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 <so...@gmail.com> ha scritto:
>> > >
>> > > > On Thu, Apr 11, 2019 at 8:09 AM Enrico Olivelli <eo...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Surefire maintenance release
Posted by Enrico Olivelli <eo...@gmail.com>.
Staging the artifact now.
It will take the whole day I guess
Enrico
Il mer 24 apr 2019, 13:21 Enrico Olivelli <eo...@gmail.com> ha scritto:
> Il giorno mer 24 apr 2019 alle ore 12:30 Tibor Digana
> <ti...@apache.org> 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 <eo...@gmail.com>
> 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 <so...@gmail.com> ha
> scritto:
> > >
> > > > On Thu, Apr 11, 2019 at 8:09 AM Enrico Olivelli <eolivelli@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
Posted by Enrico Olivelli <eo...@gmail.com>.
Il giorno mer 24 apr 2019 alle ore 12:30 Tibor Digana
<ti...@apache.org> 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 <eo...@gmail.com> 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 <so...@gmail.com> ha scritto:
> >
> > > On Thu, Apr 11, 2019 at 8:09 AM Enrico Olivelli <eo...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Surefire maintenance release
Posted by Tibor Digana <ti...@apache.org>.
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 <eo...@gmail.com> 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 <so...@gmail.com> ha scritto:
>
> > On Thu, Apr 11, 2019 at 8:09 AM Enrico Olivelli <eo...@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
Posted by Enrico Olivelli <eo...@gmail.com>.
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 <so...@gmail.com> ha scritto:
> On Thu, Apr 11, 2019 at 8:09 AM Enrico Olivelli <eo...@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
Posted by Christian Stein <so...@gmail.com>.
On Thu, Apr 11, 2019 at 8:09 AM Enrico Olivelli <eo...@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
Posted by Enrico Olivelli <eo...@gmail.com>.
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
<eo...@gmail.com> 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 <eo...@gmail.com> ha scritto:
>>
>>
>>
>> Il sab 30 mar 2019, 14:16 Enrico Olivelli <eo...@gmail.com> 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 <ol...@apache.org> ha scritto:
>>>>
>>>> On Thu, 28 Mar 2019 at 03:14, Enrico Olivelli <eo...@gmail.com> wrote:
>>>>
>>>> > Il mer 27 mar 2019, 18:10 Tibor Digana <ti...@apache.org> 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 <eo...@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 <https://s.apache.org/slack-invite#maven> channel
>>>> > > >
>>>> > > >
>>>> > > > Enrico
>>>> > > >
>>>> > > > Il giorno mer 27 mar 2019 alle ore 15:45 Tibor Digana
>>>> > > > <ti...@apache.org> 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.nicoll@gmail.com>
>>>> > > > > wrote:
>>>> > > > >
>>>> > > > > > On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana <
>>>> > > tibordigana@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
>>>> > > > > > >
>>>> > > > > > >
>>>> > > > > > > On Mon, Mar 25, 2019 at 5:11 PM Stephane Nicoll <
>>>> > > > > > stephane.nicoll@gmail.com
>>>> > > > > > > >
>>>> > > > > > > wrote:
>>>> > > > > > >
>>>> > > > > > > > Thanks for having a look Tibor!
>>>> > > > > > > >
>>>> > > > > > > > On Mon, Mar 25, 2019 at 4:37 PM Tibor Digana <
>>>> > > > tibordigana@apache.org>
>>>> > > > > > > > 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
>>>> > > > > > > > <https://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:
>>>> > > > > > > > >
>>>> > > > > > > > > <stateless-reporter
>>>> > > > > > > > >
>>>> > > > impl="org.apace.maven.plugin.surefire.report.StatelessXmlReporter">
>>>> > > > > > > <!--
>>>> > > > > > > > by
>>>> > > > > > > > > default -->
>>>> > > > > > > > > <useFileName>human readable</useFileName> <!-- default:
>>>> > > fully
>>>> > > > > > > > qualified
>>>> > > > > > > > > class name -->
>>>> > > > > > > > > <useTestCaseClass>human readable</ useTestCaseClass>
>>>> > > > > > > > > <useTestCaseMethod>human readable</ useTestCaseMethod>
>>>> > > > > > > > > </ stateless-reporter>
>>>> > > > > > > > >
>>>> > > > > > > > > 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.nicoll@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.nicoll@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 <
>>>> > > > > > > tibordigana@apache.org
>>>> > > > > > > > >
>>>> > > > > > > > > > > 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.nicoll@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
>>>> > > > > > > > > > >> >
>>>> > > > > > > > > > >>
>>>> > > > > > > > > > >
>>>> > > > > > > > > >
>>>> > > > > > > > >
>>>> > > > > > > >
>>>> > > > > > >
>>>> > > > > >
>>>> > > >
>>>> > > > ---------------------------------------------------------------------
>>>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> > > > For additional commands, e-mail: dev-help@maven.apache.org
>>>> > > >
>>>> > > >
>>>> > >
>>>> >
>>>>
>>>>
>>>> --
>>>> Olivier Lamy
>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Surefire maintenance release
Posted by Stephane Nicoll <st...@gmail.com>.
Awesome work, thank you very much Enrico!
On Wed, Apr 10, 2019 at 3:29 PM Enrico Olivelli <eo...@gmail.com> 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 <eo...@gmail.com> ha scritto:
>
> >
> >
> > Il sab 30 mar 2019, 14:16 Enrico Olivelli <eo...@gmail.com> 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 <ol...@apache.org> ha scritto:
> >>
> >>> On Thu, 28 Mar 2019 at 03:14, Enrico Olivelli <eo...@gmail.com>
> >>> wrote:
> >>>
> >>> > Il mer 27 mar 2019, 18:10 Tibor Digana <ti...@apache.org> 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 <
> eolivelli@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 <https://s.apache.org/slack-invite#maven> channel
> >>> > > >
> >>> > > >
> >>> > > > Enrico
> >>> > > >
> >>> > > > Il giorno mer 27 mar 2019 alle ore 15:45 Tibor Digana
> >>> > > > <ti...@apache.org> 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.nicoll@gmail.com>
> >>> > > > > wrote:
> >>> > > > >
> >>> > > > > > On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana <
> >>> > > tibordigana@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
> >>> > > > > > >
> >>> > > > > > >
> >>> > > > > > > On Mon, Mar 25, 2019 at 5:11 PM Stephane Nicoll <
> >>> > > > > > stephane.nicoll@gmail.com
> >>> > > > > > > >
> >>> > > > > > > wrote:
> >>> > > > > > >
> >>> > > > > > > > Thanks for having a look Tibor!
> >>> > > > > > > >
> >>> > > > > > > > On Mon, Mar 25, 2019 at 4:37 PM Tibor Digana <
> >>> > > > tibordigana@apache.org>
> >>> > > > > > > > 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
> >>> > > > > > > > <https://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:
> >>> > > > > > > > >
> >>> > > > > > > > > <stateless-reporter
> >>> > > > > > > > >
> >>> > > >
> impl="org.apace.maven.plugin.surefire.report.StatelessXmlReporter">
> >>> > > > > > > <!--
> >>> > > > > > > > by
> >>> > > > > > > > > default -->
> >>> > > > > > > > > <useFileName>human readable</useFileName> <!--
> >>> default:
> >>> > > fully
> >>> > > > > > > > qualified
> >>> > > > > > > > > class name -->
> >>> > > > > > > > > <useTestCaseClass>human readable</
> useTestCaseClass>
> >>> > > > > > > > > <useTestCaseMethod>human readable</
> >>> useTestCaseMethod>
> >>> > > > > > > > > </ stateless-reporter>
> >>> > > > > > > > >
> >>> > > > > > > > > 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.nicoll@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.nicoll@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 <
> >>> > > > > > > tibordigana@apache.org
> >>> > > > > > > > >
> >>> > > > > > > > > > > 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.nicoll@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
> >>> > > > > > > > > > >> >
> >>> > > > > > > > > > >>
> >>> > > > > > > > > > >
> >>> > > > > > > > > >
> >>> > > > > > > > >
> >>> > > > > > > >
> >>> > > > > > >
> >>> > > > > >
> >>> > > >
> >>> > > >
> >>> ---------------------------------------------------------------------
> >>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> > > > For additional commands, e-mail: dev-help@maven.apache.org
> >>> > > >
> >>> > > >
> >>> > >
> >>> >
> >>>
> >>>
> >>> --
> >>> Olivier Lamy
> >>> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>>
> >>
>
Re: Surefire maintenance release
Posted by Enrico Olivelli <eo...@gmail.com>.
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 <eo...@gmail.com> ha scritto:
>
>
> Il sab 30 mar 2019, 14:16 Enrico Olivelli <eo...@gmail.com> 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 <ol...@apache.org> ha scritto:
>>
>>> On Thu, 28 Mar 2019 at 03:14, Enrico Olivelli <eo...@gmail.com>
>>> wrote:
>>>
>>> > Il mer 27 mar 2019, 18:10 Tibor Digana <ti...@apache.org> 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 <eolivelli@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 <https://s.apache.org/slack-invite#maven> channel
>>> > > >
>>> > > >
>>> > > > Enrico
>>> > > >
>>> > > > Il giorno mer 27 mar 2019 alle ore 15:45 Tibor Digana
>>> > > > <ti...@apache.org> 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.nicoll@gmail.com>
>>> > > > > wrote:
>>> > > > >
>>> > > > > > On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana <
>>> > > tibordigana@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
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > On Mon, Mar 25, 2019 at 5:11 PM Stephane Nicoll <
>>> > > > > > stephane.nicoll@gmail.com
>>> > > > > > > >
>>> > > > > > > wrote:
>>> > > > > > >
>>> > > > > > > > Thanks for having a look Tibor!
>>> > > > > > > >
>>> > > > > > > > On Mon, Mar 25, 2019 at 4:37 PM Tibor Digana <
>>> > > > tibordigana@apache.org>
>>> > > > > > > > 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
>>> > > > > > > > <https://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:
>>> > > > > > > > >
>>> > > > > > > > > <stateless-reporter
>>> > > > > > > > >
>>> > > > impl="org.apace.maven.plugin.surefire.report.StatelessXmlReporter">
>>> > > > > > > <!--
>>> > > > > > > > by
>>> > > > > > > > > default -->
>>> > > > > > > > > <useFileName>human readable</useFileName> <!--
>>> default:
>>> > > fully
>>> > > > > > > > qualified
>>> > > > > > > > > class name -->
>>> > > > > > > > > <useTestCaseClass>human readable</ useTestCaseClass>
>>> > > > > > > > > <useTestCaseMethod>human readable</
>>> useTestCaseMethod>
>>> > > > > > > > > </ stateless-reporter>
>>> > > > > > > > >
>>> > > > > > > > > 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.nicoll@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.nicoll@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 <
>>> > > > > > > tibordigana@apache.org
>>> > > > > > > > >
>>> > > > > > > > > > > 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.nicoll@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
>>> > > > > > > > > > >> >
>>> > > > > > > > > > >>
>>> > > > > > > > > > >
>>> > > > > > > > > >
>>> > > > > > > > >
>>> > > > > > > >
>>> > > > > > >
>>> > > > > >
>>> > > >
>>> > > >
>>> ---------------------------------------------------------------------
>>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > > > For additional commands, e-mail: dev-help@maven.apache.org
>>> > > >
>>> > > >
>>> > >
>>> >
>>>
>>>
>>> --
>>> Olivier Lamy
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>
>>
Re: Surefire maintenance release
Posted by Enrico Olivelli <eo...@gmail.com>.
Il sab 30 mar 2019, 14:16 Enrico Olivelli <eo...@gmail.com> 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 <ol...@apache.org> ha scritto:
>
>> On Thu, 28 Mar 2019 at 03:14, Enrico Olivelli <eo...@gmail.com>
>> wrote:
>>
>> > Il mer 27 mar 2019, 18:10 Tibor Digana <ti...@apache.org> 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 <eo...@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 <https://s.apache.org/slack-invite#maven> channel
>> > > >
>> > > >
>> > > > Enrico
>> > > >
>> > > > Il giorno mer 27 mar 2019 alle ore 15:45 Tibor Digana
>> > > > <ti...@apache.org> 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.nicoll@gmail.com>
>> > > > > wrote:
>> > > > >
>> > > > > > On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana <
>> > > tibordigana@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
>> > > > > > >
>> > > > > > >
>> > > > > > > On Mon, Mar 25, 2019 at 5:11 PM Stephane Nicoll <
>> > > > > > stephane.nicoll@gmail.com
>> > > > > > > >
>> > > > > > > wrote:
>> > > > > > >
>> > > > > > > > Thanks for having a look Tibor!
>> > > > > > > >
>> > > > > > > > On Mon, Mar 25, 2019 at 4:37 PM Tibor Digana <
>> > > > tibordigana@apache.org>
>> > > > > > > > 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
>> > > > > > > > <https://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:
>> > > > > > > > >
>> > > > > > > > > <stateless-reporter
>> > > > > > > > >
>> > > > impl="org.apace.maven.plugin.surefire.report.StatelessXmlReporter">
>> > > > > > > <!--
>> > > > > > > > by
>> > > > > > > > > default -->
>> > > > > > > > > <useFileName>human readable</useFileName> <!--
>> default:
>> > > fully
>> > > > > > > > qualified
>> > > > > > > > > class name -->
>> > > > > > > > > <useTestCaseClass>human readable</ useTestCaseClass>
>> > > > > > > > > <useTestCaseMethod>human readable</ useTestCaseMethod>
>> > > > > > > > > </ stateless-reporter>
>> > > > > > > > >
>> > > > > > > > > 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.nicoll@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.nicoll@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 <
>> > > > > > > tibordigana@apache.org
>> > > > > > > > >
>> > > > > > > > > > > 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.nicoll@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
>> > > > > > > > > > >> >
>> > > > > > > > > > >>
>> > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > > For additional commands, e-mail: dev-help@maven.apache.org
>> > > >
>> > > >
>> > >
>> >
>>
>>
>> --
>> Olivier Lamy
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>
Re: Surefire maintenance release
Posted by Enrico Olivelli <eo...@gmail.com>.
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 <ol...@apache.org> ha scritto:
> On Thu, 28 Mar 2019 at 03:14, Enrico Olivelli <eo...@gmail.com> wrote:
>
> > Il mer 27 mar 2019, 18:10 Tibor Digana <ti...@apache.org> 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 <eo...@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 <https://s.apache.org/slack-invite#maven> channel
> > > >
> > > >
> > > > Enrico
> > > >
> > > > Il giorno mer 27 mar 2019 alle ore 15:45 Tibor Digana
> > > > <ti...@apache.org> 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.nicoll@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana <
> > > tibordigana@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
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Mar 25, 2019 at 5:11 PM Stephane Nicoll <
> > > > > > stephane.nicoll@gmail.com
> > > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Thanks for having a look Tibor!
> > > > > > > >
> > > > > > > > On Mon, Mar 25, 2019 at 4:37 PM Tibor Digana <
> > > > tibordigana@apache.org>
> > > > > > > > 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
> > > > > > > > <https://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:
> > > > > > > > >
> > > > > > > > > <stateless-reporter
> > > > > > > > >
> > > > impl="org.apace.maven.plugin.surefire.report.StatelessXmlReporter">
> > > > > > > <!--
> > > > > > > > by
> > > > > > > > > default -->
> > > > > > > > > <useFileName>human readable</useFileName> <!-- default:
> > > fully
> > > > > > > > qualified
> > > > > > > > > class name -->
> > > > > > > > > <useTestCaseClass>human readable</ useTestCaseClass>
> > > > > > > > > <useTestCaseMethod>human readable</ useTestCaseMethod>
> > > > > > > > > </ stateless-reporter>
> > > > > > > > >
> > > > > > > > > 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.nicoll@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.nicoll@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 <
> > > > > > > tibordigana@apache.org
> > > > > > > > >
> > > > > > > > > > > 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.nicoll@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
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
Re: Surefire maintenance release
Posted by Olivier Lamy <ol...@apache.org>.
On Thu, 28 Mar 2019 at 03:14, Enrico Olivelli <eo...@gmail.com> wrote:
> Il mer 27 mar 2019, 18:10 Tibor Digana <ti...@apache.org> 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 <eo...@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 <https://s.apache.org/slack-invite#maven> channel
> > >
> > >
> > > Enrico
> > >
> > > Il giorno mer 27 mar 2019 alle ore 15:45 Tibor Digana
> > > <ti...@apache.org> 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.nicoll@gmail.com>
> > > > wrote:
> > > >
> > > > > On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana <
> > tibordigana@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
> > > > > >
> > > > > >
> > > > > > On Mon, Mar 25, 2019 at 5:11 PM Stephane Nicoll <
> > > > > stephane.nicoll@gmail.com
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Thanks for having a look Tibor!
> > > > > > >
> > > > > > > On Mon, Mar 25, 2019 at 4:37 PM Tibor Digana <
> > > tibordigana@apache.org>
> > > > > > > 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
> > > > > > > <https://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:
> > > > > > > >
> > > > > > > > <stateless-reporter
> > > > > > > >
> > > impl="org.apace.maven.plugin.surefire.report.StatelessXmlReporter">
> > > > > > <!--
> > > > > > > by
> > > > > > > > default -->
> > > > > > > > <useFileName>human readable</useFileName> <!-- default:
> > fully
> > > > > > > qualified
> > > > > > > > class name -->
> > > > > > > > <useTestCaseClass>human readable</ useTestCaseClass>
> > > > > > > > <useTestCaseMethod>human readable</ useTestCaseMethod>
> > > > > > > > </ stateless-reporter>
> > > > > > > >
> > > > > > > > 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.nicoll@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.nicoll@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 <
> > > > > > tibordigana@apache.org
> > > > > > > >
> > > > > > > > > > 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.nicoll@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
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
--
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Surefire maintenance release
Posted by Enrico Olivelli <eo...@gmail.com>.
Il mer 27 mar 2019, 18:10 Tibor Digana <ti...@apache.org> 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 <eo...@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 <https://s.apache.org/slack-invite#maven> channel
> >
> >
> > Enrico
> >
> > Il giorno mer 27 mar 2019 alle ore 15:45 Tibor Digana
> > <ti...@apache.org> 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.nicoll@gmail.com>
> > > wrote:
> > >
> > > > On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana <
> tibordigana@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
> > > > >
> > > > >
> > > > > On Mon, Mar 25, 2019 at 5:11 PM Stephane Nicoll <
> > > > stephane.nicoll@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > Thanks for having a look Tibor!
> > > > > >
> > > > > > On Mon, Mar 25, 2019 at 4:37 PM Tibor Digana <
> > tibordigana@apache.org>
> > > > > > 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
> > > > > > <https://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:
> > > > > > >
> > > > > > > <stateless-reporter
> > > > > > >
> > impl="org.apace.maven.plugin.surefire.report.StatelessXmlReporter">
> > > > > <!--
> > > > > > by
> > > > > > > default -->
> > > > > > > <useFileName>human readable</useFileName> <!-- default:
> fully
> > > > > > qualified
> > > > > > > class name -->
> > > > > > > <useTestCaseClass>human readable</ useTestCaseClass>
> > > > > > > <useTestCaseMethod>human readable</ useTestCaseMethod>
> > > > > > > </ stateless-reporter>
> > > > > > >
> > > > > > > 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.nicoll@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.nicoll@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 <
> > > > > tibordigana@apache.org
> > > > > > >
> > > > > > > > > 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.nicoll@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
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Surefire maintenance release
Posted by Tibor Digana <ti...@apache.org>.
Enrico, what i maintenance release for you, 2.22.2-M1?
On Wed, Mar 27, 2019 at 6:07 PM Enrico Olivelli <eo...@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 <https://s.apache.org/slack-invite#maven> channel
>
>
> Enrico
>
> Il giorno mer 27 mar 2019 alle ore 15:45 Tibor Digana
> <ti...@apache.org> 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.nicoll@gmail.com>
> > wrote:
> >
> > > On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana <ti...@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
> > > >
> > > >
> > > > On Mon, Mar 25, 2019 at 5:11 PM Stephane Nicoll <
> > > stephane.nicoll@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Thanks for having a look Tibor!
> > > > >
> > > > > On Mon, Mar 25, 2019 at 4:37 PM Tibor Digana <
> tibordigana@apache.org>
> > > > > 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
> > > > > <https://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:
> > > > > >
> > > > > > <stateless-reporter
> > > > > >
> impl="org.apace.maven.plugin.surefire.report.StatelessXmlReporter">
> > > > <!--
> > > > > by
> > > > > > default -->
> > > > > > <useFileName>human readable</useFileName> <!-- default: fully
> > > > > qualified
> > > > > > class name -->
> > > > > > <useTestCaseClass>human readable</ useTestCaseClass>
> > > > > > <useTestCaseMethod>human readable</ useTestCaseMethod>
> > > > > > </ stateless-reporter>
> > > > > >
> > > > > > 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.nicoll@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.nicoll@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 <
> > > > tibordigana@apache.org
> > > > > >
> > > > > > > > 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.nicoll@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
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Surefire maintenance release
Posted by Enrico Olivelli <eo...@gmail.com>.
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
<ti...@apache.org> 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 <st...@gmail.com>
> wrote:
>
> > On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana <ti...@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
> > >
> > >
> > > On Mon, Mar 25, 2019 at 5:11 PM Stephane Nicoll <
> > stephane.nicoll@gmail.com
> > > >
> > > wrote:
> > >
> > > > Thanks for having a look Tibor!
> > > >
> > > > On Mon, Mar 25, 2019 at 4:37 PM Tibor Digana <ti...@apache.org>
> > > > 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
> > > > <https://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:
> > > > >
> > > > > <stateless-reporter
> > > > > impl="org.apace.maven.plugin.surefire.report.StatelessXmlReporter">
> > > <!--
> > > > by
> > > > > default -->
> > > > > <useFileName>human readable</useFileName> <!-- default: fully
> > > > qualified
> > > > > class name -->
> > > > > <useTestCaseClass>human readable</ useTestCaseClass>
> > > > > <useTestCaseMethod>human readable</ useTestCaseMethod>
> > > > > </ stateless-reporter>
> > > > >
> > > > > 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.nicoll@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.nicoll@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 <
> > > tibordigana@apache.org
> > > > >
> > > > > > > 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.nicoll@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
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Surefire maintenance release
Posted by Tibor Digana <ti...@apache.org>.
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 <st...@gmail.com>
wrote:
> On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana <ti...@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
> >
> >
> > On Mon, Mar 25, 2019 at 5:11 PM Stephane Nicoll <
> stephane.nicoll@gmail.com
> > >
> > wrote:
> >
> > > Thanks for having a look Tibor!
> > >
> > > On Mon, Mar 25, 2019 at 4:37 PM Tibor Digana <ti...@apache.org>
> > > 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
> > > <https://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:
> > > >
> > > > <stateless-reporter
> > > > impl="org.apace.maven.plugin.surefire.report.StatelessXmlReporter">
> > <!--
> > > by
> > > > default -->
> > > > <useFileName>human readable</useFileName> <!-- default: fully
> > > qualified
> > > > class name -->
> > > > <useTestCaseClass>human readable</ useTestCaseClass>
> > > > <useTestCaseMethod>human readable</ useTestCaseMethod>
> > > > </ stateless-reporter>
> > > >
> > > > 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.nicoll@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.nicoll@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 <
> > tibordigana@apache.org
> > > >
> > > > > > 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.nicoll@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
Posted by Stephane Nicoll <st...@gmail.com>.
On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana <ti...@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
>
>
> On Mon, Mar 25, 2019 at 5:11 PM Stephane Nicoll <stephane.nicoll@gmail.com
> >
> wrote:
>
> > Thanks for having a look Tibor!
> >
> > On Mon, Mar 25, 2019 at 4:37 PM Tibor Digana <ti...@apache.org>
> > 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
> > <https://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:
> > >
> > > <stateless-reporter
> > > impl="org.apace.maven.plugin.surefire.report.StatelessXmlReporter">
> <!--
> > by
> > > default -->
> > > <useFileName>human readable</useFileName> <!-- default: fully
> > qualified
> > > class name -->
> > > <useTestCaseClass>human readable</ useTestCaseClass>
> > > <useTestCaseMethod>human readable</ useTestCaseMethod>
> > > </ stateless-reporter>
> > >
> > > 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.nicoll@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.nicoll@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 <
> tibordigana@apache.org
> > >
> > > > > 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.nicoll@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
Posted by Tibor Digana <ti...@apache.org>.
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 <st...@gmail.com>
wrote:
> Thanks for having a look Tibor!
>
> On Mon, Mar 25, 2019 at 4:37 PM Tibor Digana <ti...@apache.org>
> 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
> <https://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:
> >
> > <stateless-reporter
> > impl="org.apace.maven.plugin.surefire.report.StatelessXmlReporter"> <!--
> by
> > default -->
> > <useFileName>human readable</useFileName> <!-- default: fully
> qualified
> > class name -->
> > <useTestCaseClass>human readable</ useTestCaseClass>
> > <useTestCaseMethod>human readable</ useTestCaseMethod>
> > </ stateless-reporter>
> >
> > 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.nicoll@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.nicoll@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 <tibordigana@apache.org
> >
> > > > 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.nicoll@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
Posted by Stephane Nicoll <st...@gmail.com>.
Thanks for having a look Tibor!
On Mon, Mar 25, 2019 at 4:37 PM Tibor Digana <ti...@apache.org> 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
<https://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:
>
> <stateless-reporter
> impl="org.apace.maven.plugin.surefire.report.StatelessXmlReporter"> <!-- by
> default -->
> <useFileName>human readable</useFileName> <!-- default: fully qualified
> class name -->
> <useTestCaseClass>human readable</ useTestCaseClass>
> <useTestCaseMethod>human readable</ useTestCaseMethod>
> </ stateless-reporter>
>
> 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.nicoll@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.nicoll@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 <ti...@apache.org>
> > > 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.nicoll@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
Posted by Tibor Digana <ti...@apache.org>.
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:
<stateless-reporter
impl="org.apace.maven.plugin.surefire.report.StatelessXmlReporter"> <!-- by
default -->
<useFileName>human readable</useFileName> <!-- default: fully qualified
class name -->
<useTestCaseClass>human readable</ useTestCaseClass>
<useTestCaseMethod>human readable</ useTestCaseMethod>
</ stateless-reporter>
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 <st...@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.nicoll@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 <ti...@apache.org>
> > 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.nicoll@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
Posted by Stephane Nicoll <st...@gmail.com>.
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 <st...@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 <ti...@apache.org>
> 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.nicoll@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
Posted by Christian Stein <so...@gmail.com>.
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 <eo...@gmail.com> wrote:
> +1
>
> Il mar 19 mar 2019, 22:29 Olivier Lamy <ol...@apache.org> ha scritto:
>
> > Sounds good to have a maintenance release with this!
> >
> > On Thu, 14 Mar 2019 at 04:34, Enrico Olivelli <eo...@gmail.com>
> wrote:
> >
> > > Very good!
> > >
> > > Enrico
> > >
> > > Il mer 13 mar 2019, 16:09 Stephane Nicoll <st...@gmail.com>
> 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 <tibordigana@apache.org
> >
> > > > 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.nicoll@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
Posted by Enrico Olivelli <eo...@gmail.com>.
+1
Il mar 19 mar 2019, 22:29 Olivier Lamy <ol...@apache.org> ha scritto:
> Sounds good to have a maintenance release with this!
>
> On Thu, 14 Mar 2019 at 04:34, Enrico Olivelli <eo...@gmail.com> wrote:
>
> > Very good!
> >
> > Enrico
> >
> > Il mer 13 mar 2019, 16:09 Stephane Nicoll <st...@gmail.com> 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 <ti...@apache.org>
> > > 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.nicoll@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
Posted by Olivier Lamy <ol...@apache.org>.
Sounds good to have a maintenance release with this!
On Thu, 14 Mar 2019 at 04:34, Enrico Olivelli <eo...@gmail.com> wrote:
> Very good!
>
> Enrico
>
> Il mer 13 mar 2019, 16:09 Stephane Nicoll <st...@gmail.com> 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 <ti...@apache.org>
> > 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.nicoll@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
Posted by Enrico Olivelli <eo...@gmail.com>.
Very good!
Enrico
Il mer 13 mar 2019, 16:09 Stephane Nicoll <st...@gmail.com> 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 <ti...@apache.org>
> 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.nicoll@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
> > >
> >
>