Stephane, What exists in our agreement are two issues (SUREFIRE-1546 and SUREFIRE-1614), you will have them but no multiple releases (not effective in the perspectives of out spare time). We need people like you who will support us in 3.0.0-M4. This is the main goal. The issues SUREFIRE-1546 and SUREFIRE-1614 will be delivered to you, but no more and not less. The thing is how you will participate by your hands in Java code. The result depends on you. But again, this what we solve here is not important for ASF. It is important for you and your agenda. For the project is important the deal we made several years ago, when we planned to provide Extensions API for the Users. To get there we need to unfortunately rework internal code in Surefire project which takes really a lots of time and spends private energy, and thus 2.22.2 is less important from this perspective. We have to support long standing vision but the version 2.22.2 is something short lasting which you and some Spring guys wanted due to they have a problem* with their own internal rules* and technically Spring project can solve this problem with 3.0.0-M3. Therefore we are wasting the time if we write the code for you. Therefore you should provide pull request by yourself as this is OSS and we can make a code review. But our effort would be really only short time relevant if we dedicate too much time in 2.22.2 with these two Jira issues. We have few active Java developers and "stealing" them for your activity means that we are not effective and slow. Therefore, Stephane pls prepare the commits on your responsibility on GitHub in your pull request and we can invest the time to check it including the build check and cutting the release version.
T On Wed, Mar 27, 2019 at 8:11 AM Stephane Nicoll <[email protected]> wrote: > 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 > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > > > > > >
