Hi Benedikt, I do not have any problem with SNAPSHOT version in the branch junit5. Even this can be very easily accomplished. Let's put property, e.g. version.junit5, into [1] and reference to this POM via parent declaration in your root POM of particular IT having JUnit5 tests. [1] https://github.com/apache/maven-surefire/blob/master/surefire-integration-tests/src/test/resources/pom.xml
On Mon, Oct 10, 2016 at 6:43 PM, Benedikt Ritter [via Maven] < ml-node+s40175n5882740...@n5.nabble.com> wrote: > Hi, > > I've had the chance to talk to Marc Philipp from the JUnit team again, and > I'd like to share with you some of our discussions. > > First we talked about the progress with the surefire provider: > Currently I've done not much. We have a junit5 branch with a single PR > merged (the JUnit5VersionsIT). Further more we have some pending PRs which > need to be reviewed/merged. We haven't done any "real" development yet. > > I told Marc that a problem with implementing the ITs at the moment is, > that > the JUnit 5.0.0-m2 provider implementation is very limited. So we thought > it may be a good thing to depend on the SNAPSHOT of JUnit5 in the junit5 > as > long as we do not have our own implementation. This may be fragile, but we > can pick up the latest changes to the provider implementation. > > Then we talked about moving the provider code from junit to > maven-surefire. > This is clearly the preferred way to go for the junit team. From a user > perspective it would also be better to not have a junit provider and a > maven-surefire provider for junit5. > > The problem we identified may be when this code could be released at > maven-surefire. Currently JUnit 5 GA is expected sometime in early 2017. > If > the provider code is moved to maven-surefire there should be a release > very > soon after the JUnit 5 GA release. Otherwise nobody can use JUnit 5 with > maven. > The alternative would be, that JUnit releases the provider implementation > when they go GA and after that the code is moved to surefire. The problem > with this approach is, that it may lead to confusion for the users. > > My personal view is, that it would be good to integrate the provider code > into maven-surefire as soon as possible, but I not yet firm enough with > the > code base the be really productive. I hope to get a better understanding > of > the codebase during the next few weeks. > > Regards, > Benedikt > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > http://maven.40175.n5.nabble.com/SUREFIRE-Hangout-with- > Marc-Philipp-tp5882740.html > To start a new topic under Maven Developers, email > ml-node+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-Hangout-with-Marc-Philipp-tp5882870.html Sent from the Maven Developers mailing list archive at Nabble.com.
