Hi all, here are my 0.02 € on the two issues/PRs that went into Surefire 3.x already.
*SUREFIRE-1546 "JUnit 5 display names"* Both, supporting "@DisplayName" and therefore also backporting https://issues.apache.org/jira/browse/SUREFIRE-1546 to the 2.x branch makes almost *no* sense to me. Surefire (and every other testing tool out there using the XML format defined by Ant) suffers the same limitations as the JUnit Platform ConsoleLauncher: display names may be used on the console when logging test run progress or results to the user in a human-friendly manner - but display names in XML / text reports as (unique !) identifiers will either break due to file system constraints or cause downstream processes choke. See this answer for some more details [1]. I support having this feature as an optional feature, as suggested by Tibor. Users who know what they do, may enable it at their own risk. Further work should be directed to [2] "Define a standard for test reports" -- everybody feel invited to contribute! *SUREFIRE-1614 "**JUnit's Vintage Engine* *corrupts Surefire's STDOUT* *" * Changes made in [3] are not numerous. Methinks, if there was a Surefire 2.22.x branch, then commit [4] could be cherry-picked to it and Surefire 2.22.2 released shortly after that. Tibor, on which commit would such a bug-fix branched be based on? [5] or later to also include Java 11 support? Cheers, Christian [1] https://issues.apache.org/jira/browse/SUREFIRE-1546?focusedCommentId=16758470&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16758470 [2] https://github.com/ota4j-team/opentest4j/issues/9 [3] https://github.com/apache/maven-surefire/pull/209/files [4] https://github.com/apache/maven-surefire/commit/f517d349ede0e15229e3c48f45d10dabc72a3fc9 [5] https://github.com/apache/maven-surefire/commit/19006aa70f36705f399b8c105a16f636904f00f3 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 > > >
