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 <tibordig...@apache.org>
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 <tibordig...@apache.org>
> 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] <
>> 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?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.
>
>
>

Reply via email to