This is the final branch from which I will cut the release. https://github.com/apache/maven-surefire/tree/release/2.22.2
Re-launched Jenkins to check for the last time: https://builds.apache.org/job/maven-box/job/maven-surefire/job/release%252F2.22.2/ Enrico Il giorno mer 10 apr 2019 alle ore 14:23 Enrico Olivelli <eolive...@gmail.com> ha scritto: > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
