Stephane, >> I wanted to make sure that the JUnit5 story was functional
I really don't like politics. Did you see SUREFIRE-1614? 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. 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 > > > >> > > > > >> > > > > > > > > > >
