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 > > > > >> > > > > > >> > > > > > > > > > > > > > > >
