You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Enrico Olivelli <eo...@gmail.com> on 2019/04/01 14:09:39 UTC
Re: Surefire maintenance release
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>.
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
>>>
>>