The diff looks good.
Stephane, I guess this only 50% work you wanted to have.
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 <stephane.nic...@gmail.com>
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 <stephane.nic...@gmail.com
> >
> 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 <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
> >> >
> >>
> >
>
