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