Awesome work, thank you very much Enrico! On Wed, Apr 10, 2019 at 3:29 PM Enrico Olivelli <eolive...@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 <eolive...@gmail.com> ha scritto: > > > > > > > Il sab 30 mar 2019, 14:16 Enrico Olivelli <eolive...@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 <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 > >>> > >> >
