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 >> >
