Hello Tibor, okay, I will prepare something, after we have integrated the parameterized JUnit4VersionsIT into junit5 branch.
Tibor Digana <[email protected]> schrieb am Di., 11. Okt. 2016 um 19:50 Uhr: > Sorry for my typos, again: > *Maybe we should setup second trigger in Jenkins build for junir5 branch > and run ASF build if any change is pushed to ASF or JUnit Git repository.* > > On Tue, Oct 11, 2016 at 7:48 PM, Tibor Digana <[email protected]> > wrote: > > > We can follow already existing principle and declare JUnit5 version in > [1]. > > There is already such good example: > > > > <systemPropertyVariables> > > <surefire.version>${project.version}</surefire.version> > > <testng.version>${testng.version}</testng.version> > > > > [1] https://github.com/apache/maven-surefire/blob/master/ > > surefire-integration-tests/pom.xml > > > > Regarding Surefire JUnit5 Provider, you can integrate it right now since > > the branch *junit5 *is apart of master. > > I think this would be quite good signal sent outside as well. > > The drawback is a little work in *AbstractSurefireMojo.java* at the > > starting point when the provider is being moved. > > I don't know how easy it would be to frequently migrate all changes but > we > > can have some intermediate step and that is surefire-junit5 provider as a > > new module dependent on SNAPSHOT of JUnit5 provider. This means our > provide > > can be a kind of wrapper around real provider in JUnit5 project. This way > > we have ITs and immediate reflection of changes in JUnit5 project. Maybe > we > > should setup second trigger in Jenkins build and run ASF build if any > > change in pushed to ASF of JUnit Git repository. > > > > > > > > > > On Tue, Oct 11, 2016 at 1:25 PM, Tibor Digana <[email protected]> > > wrote: > > > >> 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/surefir > >> e-integration-tests/src/test/resources/pom.xml > >> > >> > >> On Mon, Oct 10, 2016 at 6:43 PM, Benedikt Ritter [via Maven] < > >> [email protected]> 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 > >> > [email protected] > >> > To unsubscribe from Maven Developers, click here > >> > <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?m > >> acro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYX > >> BhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==> > >> > . > >> > NAML > >> > <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?m > >> acro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base > >> =nabble.naml.namespaces.BasicNamespace-nabble.view.web. > >> template.NabbleNamespace-nabble.view.web.template.NodeNamesp > >> ace&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.c > >> om/Re-SUREFIRE-Hangout-with-Marc-Philipp-tp5882870.html > >> Sent from the Maven Developers mailing list archive at Nabble.com. > > > > > > >
