Sorry for the delay The work branch seems in good shape. Now it is only a matter or cutting the release
Enrico Il lun 1 apr 2019, 16:09 Enrico Olivelli <eolive...@gmail.com> ha scritto: > > > Il sab 30 mar 2019, 14:16 Enrico Olivelli <eolive...@gmail.com> ha > scritto: > >> I have created a PR for your work Stephane >> https://github.com/apache/maven-surefire/pull/225 >> >> I will do my best >> I am still new to the release procedure, never cut a release for surefire >> and we usually are only cutting releases from master. >> > > We are experiencing integration tests failures I am checking with Chris. > Any help is appreciated > > Enrico > > > >> >> Enrico >> >> >> >> Il gio 28 mar 2019, 00:34 Olivier Lamy <ol...@apache.org> ha scritto: >> >>> On Thu, 28 Mar 2019 at 03:14, Enrico Olivelli <eolive...@gmail.com> >>> wrote: >>> >>> > Il mer 27 mar 2019, 18:10 Tibor Digana <tibordig...@apache.org> ha >>> > scritto: >>> > >>> > > Enrico, what i maintenance release for you, 2.22.2-M1? >>> > > >>> > >>> > 2.22.2 without suffix >>> > >>> >>> +1 >>> @Tibor if you are too busy maybe Enrico can cut the release if he has >>> time. >>> >>> >>> > >>> > >>> > Enrico >>> > >>> > > >>> > > >>> > > >>> > > >>> > > On Wed, Mar 27, 2019 at 6:07 PM Enrico Olivelli <eolive...@gmail.com >>> > >>> > > wrote: >>> > > >>> > > > Stephane >>> > > > thank you so much. >>> > > > I think we will be able to cut a maintenaince release soon with >>> your >>> > > > branch. >>> > > > >>> > > > Maybe you can join us in chat with >>> https://s.apache.org/slack-invite >>> > > > #maven <https://s.apache.org/slack-invite#maven> channel >>> > > > >>> > > > >>> > > > Enrico >>> > > > >>> > > > Il giorno mer 27 mar 2019 alle ore 15:45 Tibor Digana >>> > > > <tibordig...@apache.org> ha scritto: >>> > > > > >>> > > > > 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 < >>> > > > stephane.nic...@gmail.com> >>> > > > > wrote: >>> > > > > >>> > > > > > On Tue, Mar 26, 2019 at 12:26 PM Tibor Digana < >>> > > tibordig...@apache.org> >>> > > > > > 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 < >>> > > > > > stephane.nic...@gmail.com >>> > > > > > > > >>> > > > > > > wrote: >>> > > > > > > >>> > > > > > > > Thanks for having a look Tibor! >>> > > > > > > > >>> > > > > > > > On Mon, Mar 25, 2019 at 4:37 PM Tibor Digana < >>> > > > tibordig...@apache.org> >>> > > > > > > > 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 < >>> > > > > > > > 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 >>> > > > > > > > > > >> > >>> > > > > > > > > > >> >>> > > > > > > > > > > >>> > > > > > > > > > >>> > > > > > > > > >>> > > > > > > > >>> > > > > > > >>> > > > > > >>> > > > >>> > > > >>> --------------------------------------------------------------------- >>> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> > > > For additional commands, e-mail: dev-h...@maven.apache.org >>> > > > >>> > > > >>> > > >>> > >>> >>> >>> -- >>> Olivier Lamy >>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>> >>
