Hello Tibor, thank you for sharing your thoughts and thank you for the review.
> Am 10.06.2017 um 12:48 schrieb Tibor Digana <tibordig...@apache.org>: > > Both branches are messy. > 3.0-rc1 is pretty old and not working properly because one IT fails. > I wanted to continue on 3.0 two years ago but could not because the plugin > was unstable and the 3.0 Extensions was undefined. The way to have > extensions is clear to me now. Currently now the plugin is able to work > with Maven 3 so the stability has higher preference. So I wanted release > 2.20.1 by the end of this week and then 2.20.2 with JDK 9. After this we > have nothing to fix in stability. > > The JUnit 5 should go to one branch. I do not know why I was so liberal to > accept pushing JUnit 5 provider to 3.0-rc1 branch. Anyway I do not want to > push branches junit5 and 3.0-rc1 directly to master now because it is > technically impossible. Instead I would like to create a patch from > 3.0-rc1, test it, apply the patch in another branch on the top of master > HEAD and commit consistent single commit to new branch 3.0-alpha1 and then > JUnit 5 patch to another branch. These branches will be used for code > review before pushing directly to master. This is usual process. Meanwhile > the branches will be in progress there will be no other activity due to > these are very big and merge conflicts should be avoided. > > So I would propose committing all code related to JUnit 5 to branch junit5 > include changes in AbstractSurefireMojo and add ITs which are necessary. > At the time when we prepare branch for code review we need to have tests to > make sure the code is not risky. > Okay, so let me propose this: I will create a new PR targeted at the junit5 branch, where I will cherry-pick to commits with the provider code. Then I create another PR to remove the provider code vom 3.0-rc1 branch again. This way we have the junit 5 code in a separate branch and can decide where we want to merge it to. Regards, Benedikt > > On Sat, Jun 10, 2017 at 11:24 AM, Tibor Digana-2 [via Maven] < > ml+s40175n5909755...@n5.nabble.com> wrote: > >> Pls give me time to read it. >> >> On Sat, Jun 10, 2017 at 11:06 AM, Benedikt Ritter <[hidden email] >> <http:///user/SendEmail.jtp?type=node&node=5909755&i=0>> >> wrote: >> >>> Hey guys, >>> >>> any thoughts on this? >>> >>> Benedikt >>> >>> Benedikt Ritter <[hidden email] >> <http:///user/SendEmail.jtp?type=node&node=5909755&i=1>> schrieb am Do. >> 8. Juni 2017 um 15:16: >>> >>>> Hello, >>>> >>>> first of all, I’d like to apologize for not being very active over the >>>> past few months. I’ve been busy at work and there was ApacheCON… so >> you >>>> know how it is :-) >>>> >>>> I’d like to take some time to review where we’re standing with JUnit 5 >>>> support and what we our next steps will be. Currently the whole thing >> is >>> a >>>> little bit messed up and I’m pretty much to blame for this: >>>> >>>> - we have a junit5 branch, where I started to implement some >> integration >>>> tests for JUnit 5 support. There are no code changes to Surefire >> itself >>> in >>>> this branch. It just tests that specifying the provider explicitly >> does >>>> work as shown in the JUnit docs. >>>> - then we have 3.0-rc1. We have merged the Provider code from the >> JUnit >>>> team into this branch. But we don’t have any tests there. >>>> - I’ve created a new PR to get work started on a ProviderInfo >>>> implementation to enable automatic provider lookup [1]. This way users >>>> don’t need to specify the provider explicitly anymore. >>>> >>>> So what should be our next steps? >>>> >>>> I think we should merge the junit5 branch into the 3.0-rc1 branch, so >>> that >>>> we have the existing integration tests we already implemented in place >>> for >>>> getting the work on the ProviderInfo started. >>>> Then we will need some time to clean up the integration test project. >> I >>>> think it need to be restructured a little bit to make it easier to >>>> understand and make it possible to run tests against several JUnit >>> versions. >>>> In the end we should be able to verify that all existing JUnit 4 also >>> work >>>> with the JUnit 5 provider. >>>> >>>> @Tibor: Can you merge the junit5 branch to 3.0-rc1 branch? Or should I >>>> create a PR for this? >>>> >>>> Best regards, >>>> Benedikt >>>> >>>> [1] https://github.com/apache/maven-surefire/pull/153 >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [hidden email] >> <http:///user/SendEmail.jtp?type=node&node=5909755&i=2> >>>> For additional commands, e-mail: [hidden email] >> <http:///user/SendEmail.jtp?type=node&node=5909755&i=3> >>>> >>>> >>> >> >> >> >> -- >> Cheers >> Tibor >> >> >> ------------------------------ >> If you reply to this email, your message will be added to the discussion >> below: >> http://maven.40175.n5.nabble.com/Re-SUREFIRE-JUnit-5- >> support-current-state-and-next-steps-tp5909754p5909755.html >> To start a new topic under Maven Developers, email >> ml+s40175n142166...@n5.nabble.com >> To unsubscribe from Maven Developers, click here >> <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==> >> . >> NAML >> <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> >> > > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Re-SUREFIRE-JUnit-5-support-current-state-and-next-steps-tp5909754p5909756.html > Sent from the Maven Developers mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
