Enrico, what i maintenance release for you, 2.22.2-M1?
On Wed, Mar 27, 2019 at 6:07 PM Enrico Olivelli <[email protected]> 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 > <[email protected]> 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 < > [email protected]> > > wrote: > > > > > On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana <[email protected]> > > > 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 < > > > [email protected] > > > > > > > > > wrote: > > > > > > > > > Thanks for having a look Tibor! > > > > > > > > > > On Mon, Mar 25, 2019 at 4:37 PM Tibor Digana < > [email protected]> > > > > > 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 < > > > > > [email protected] > > > > > > > > > > > > > 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 < > > > > > > [email protected] > > > > > > > > > > > > > > > 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 < > > > > [email protected] > > > > > > > > > > > > > > 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 < > > > > > > > >> [email protected]> > > > > > > > >> 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: [email protected] > For additional commands, e-mail: [email protected] > >
