I have created a PR for your work Stephane https://github.com/apache/maven-surefire/pull/225
I will do my best I am still new to the release procedure, never cut a release for surefire and we usually are only cutting releases from master. Enrico Il gio 28 mar 2019, 00:34 Olivier Lamy <ol...@apache.org> ha scritto: > On Thu, 28 Mar 2019 at 03:14, Enrico Olivelli <eolive...@gmail.com> wrote: > > > Il mer 27 mar 2019, 18:10 Tibor Digana <tibordig...@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 <eolive...@gmail.com> > > > wrote: > > > > > > > Stephane > > > > thank you so much. > > > > I think we will be able to cut a maintenaince release soon with your > > > > branch. > > > > > > > > Maybe you can join us in chat with https://s.apache.org/slack-invite > > > > #maven <https://s.apache.org/slack-invite#maven> channel > > > > > > > > > > > > Enrico > > > > > > > > Il giorno mer 27 mar 2019 alle ore 15:45 Tibor Digana > > > > <tibordig...@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.nic...@gmail.com> > > > > > wrote: > > > > > > > > > > > On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana < > > > tibordig...@apache.org> > > > > > > wrote: > > > > > > > > > > > > > Stephane, > > > > > > > > > > > > > > >> I wanted to make sure that the JUnit5 story was functional > > > > > > > > > > > > > > I really don't like politics. > > > > > > > > > > > > > > > > > > What's that supposed to mean? If you want to quote something, > > please > > > > quote > > > > > > the full sentence. The full sentence is *"I wanted to make sure > > that > > > > the > > > > > > JUnit5 story was functional with the vintage engine and the > current > > > GA > > > > of > > > > > > surefire." *which I believe is an accurate description of the > > current > > > > > > situation. > > > > > > > > > > > > > > > > > > > Did you see SUREFIRE-1614? > > > > > > > > > > > > > > > > > > I did, that's the issue I backported. What are you talking about? > > > > > > > > > > > > > > > > > > > > > > > > > It really does not > > > > > > > break functionality (only affects logger) and SUREFIRE-1614 is > > not > > > > worth > > > > > > of > > > > > > > making release with single improvement. If you want to be > > > > consistent, you > > > > > > > should stand on your original list of issues in your first > email > > > and > > > > this > > > > > > > is: SUREFIRE-1546 and SUREFIRE-1614. > > > > > > > > > > > > > > > > > > > I wanted to but someone from the JUnit team said that backporting > > > that > > > > > > second issue "makes no sense". What am I supposed to do with that > > > > > > information exactly? > > > > > > > > > > > > At the end of the day, you decide what the outcome of this > request > > > has > > > > to > > > > > > be. Spring Boot can't upgrade its base usage to JUnit 5 because > it > > > > does not > > > > > > work properly when combined with the vintage engine. That's all I > > am > > > > trying > > > > > > to fix. > > > > > > > > > > > > I also think that It doesn't matter how many issues you have > fixed > > > in a > > > > > > maintenance release as long as that helps the community. Others > > > members > > > > > > here have expressed a +1 to that proposal. > > > > > > > > > > > > Thanks, > > > > > > S. > > > > > > > > > > > > > > > > > > > > > > > > > We in Slack discuss technical details what we do in milestone > > > > versions. > > > > > > > Enrico and Christian are active developers but we need to have > > more > > > > > > > developers like you Stephane and I would appreciate to have > > > > additionally > > > > > > > the previous developers on the board as well and grow the team, > > > i.e. > > > > > > > Andreas and Kristian. > > > > > > > > > > > > > > Cheers > > > > > > > Tibor > > > > > > > > > > > > > > > > > > > > > On Mon, Mar 25, 2019 at 5:11 PM Stephane Nicoll < > > > > > > stephane.nic...@gmail.com > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Thanks for having a look Tibor! > > > > > > > > > > > > > > > > On Mon, Mar 25, 2019 at 4:37 PM Tibor Digana < > > > > tibordig...@apache.org> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > The diff looks good. > > > > > > > > > > > > > > > > > > Stephane, I guess this only 50% work you wanted to have. > > > > > > > > > > > > > > > > > > > > > > > > > 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.nic...@gmail.com > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Hey, > > > > > > > > > > > > > > > > > > > > Can someone working on surefire confirm the interest of > > > > creating > > > > > > that > > > > > > > > > > branch in the main repo and kick-off a release if a > review > > is > > > > > > > > > satisfactory? > > > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > S. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 13, 2019 at 4:09 PM Stephane Nicoll < > > > > > > > > > stephane.nic...@gmail.com > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Hey, > > > > > > > > > > > > > > > > > > > > > > I've created a `2.22.x` branch based on the 2.22.1 tag > > and > > > > I've > > > > > > > > > > > cherry-picked the issue we need to get proper support > for > > > the > > > > > > > vintage > > > > > > > > > > > engine[1] > > > > > > > > > > > > > > > > > > > > > > This 2.22.2-SNAPSHOT works for our purpose so I was > > > > wondering if > > > > > > > more > > > > > > > > > > > fixes could be backported and/or if someone would like > to > > > > review > > > > > > > > those > > > > > > > > > > > changes. > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > S. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1] > > https://github.com/snicoll/maven-surefire/tree/2.22.x > > > > > > > > > > > > > > > > > > > > > > On Wed, Feb 27, 2019 at 1:46 PM Tibor Digana < > > > > > > > tibordig...@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.nic...@gmail.com> > > > > > > > > > > >> wrote: > > > > > > > > > > >> > > > > > > > > > > >> > Hi everyone, > > > > > > > > > > >> > > > > > > > > > > > >> > It's great to see the progress on Surefire 3.0 and I > > > > wanted to > > > > > > > > reach > > > > > > > > > > >> out to > > > > > > > > > > >> > discuss a practicable problem with the 2.x line. > There > > > > are a > > > > > > > > number > > > > > > > > > of > > > > > > > > > > >> > fixes for JUnit 5 that are only available in the 3.x > > > line > > > > that > > > > > > > > isn't > > > > > > > > > > GA > > > > > > > > > > >> > yet. [1][2] > > > > > > > > > > >> > > > > > > > > > > > >> > Putting my Spring Boot hat for a min, this actually > > > > prevents > > > > > > us > > > > > > > > from > > > > > > > > > > >> > upgrading our test support to JUnit 5: our plan is > to > > > > offer > > > > > > > > maximum > > > > > > > > > > >> > flexibility by providing the vintage engine (so that > > > > users can > > > > > > > > keep > > > > > > > > > > >> their > > > > > > > > > > >> > tests and migrate at their own pace). > > > > > > > > > > >> > > > > > > > > > > > >> > We can't upgrade to a milestone as our upgrade > policy > > > > prevents > > > > > > > > that > > > > > > > > > > >> > (regardless of how stable this is and especially > since > > > > > > backward > > > > > > > > > > >> > incompatible changes have been pushed to the latest > > > > > > milestone). > > > > > > > So > > > > > > > > > > we're > > > > > > > > > > >> > kind of stuck. > > > > > > > > > > >> > > > > > > > > > > > >> > Would there be an appetite to backport those fixes > and > > > > > > release a > > > > > > > > > > 2.22.2? > > > > > > > > > > >> > > > > > > > > > > > >> > Thanks, > > > > > > > > > > >> > S. > > > > > > > > > > >> > > > > > > > > > > > >> > [1] > > https://issues.apache.org/jira/browse/SUREFIRE-1614 > > > > > > > > > > >> > [2] > > > > > > > > > > >> > > > > > > > > > > > > > https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546 > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > -- > Olivier Lamy > http://twitter.com/olamy | http://linkedin.com/in/olamy >
