Both old Jenkins builds [1] already use JDK 8.
So this should not be a problem.

[1]
https://builds.apache.org/job/maven-surefire/
https://builds.apache.org/job/maven-surefire-windows/


On Mon, Oct 10, 2016 at 7:03 PM, Benedikt Ritter [via Maven] <
ml-node+s40175n5882750...@n5.nabble.com> wrote:

> Hello again,
>
> Tibor Digana <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5882750&i=0>> schrieb am Mi.,
> 5. Okt. 2016 um
> 00:05 Uhr:
>
> > >>Or do we want to even share the test projects and work with profiles
> in
> > the test project pom?
> >
> > I mean this.
> >
> > It pretty depends on what we are going to test, either:
> > + features of surefire-junit5 provider, or
> > + features of junit5 itself.
> >
> > I would say the provider in the first phase, and in the second phase we
> > should identify junit5 features which do not exist in junit4 but may
> > influence, e.g. Surefire report.
> >
> > The main purpose of integration testing is the interoperability between
> the
> > main process of Maven and surefire (forked jvm or in-plugin process).
> >
> > This would lower the development time because you can already reuse
> > existing tests.
> > It would be nice to have profiles for vintage and jupiter. If we find
> out
> > difference between reports, this can be a subject to a discovered bug.
> > I think we can keep all IT projects and IT classes where they are and we
> > can also keep sources using JUnit4 annotations together with JUnit5
> > annotations. The best was that you split the JUni5 project into
> > junit-jupiter-api and the core modules.
> > If we just add junit-jupiter-api to the main <dependencies/> section in
> > every POM, we do not break old tests because JUnit5 annotations do not
> > break JUnit4 runners. If we want to run JUnit5 tests, then the profiles
> > come into the role (one having junit-jupiter-engine
> > <https://github.com/junit-team/junit5/tree/master/junit-jupiter-engine>
> > and
> > another profile with junit-vintage-engine
> > <https://github.com/junit-team/junit5/tree/master/junit-vintage-engine>,
>
> > and finally profiles for old junit4 or 47). Unfortunately JUnit4 does
> not
> > have separate module with annotations only. Therefore we may use
> > <classpathDependencyExcludes/> to exclude it if really necessary, see
> >
> > http://maven.apache.org/surefire/maven-surefire-
> plugin/examples/configuring-classpath.html
> > Do you think this would work?
> >
>
> I found a way to this. I've modified the Junit4VersionIT again to run
> against JUnit 4 and JUnit 5.
>
> Drawbacks:
> - all tests have to be run on Java 8. Otherwise we can't have the JUnit 5
> annotations
> - the profile for the jupiter engine also needs a dependency to junit 4.x.
> Otherwise we get a compilation error because the old annotations are not
> available.
>
> I think this could be a starting point. After we have merged #126 from
> GitHub, I can build this on top the parameterized test.
>
> Regards,
> Benedikt
>
>
> >
> > Cheers
> > Tibor
> >
> >
> > On Tue, Oct 4, 2016 at 7:48 PM, Benedikt Ritter [via Maven] <
> > [hidden email] <http:///user/SendEmail.jtp?type=node&node=5882750&i=1>>
> wrote:
> >
> > > Hello Tibor,
> > >
> > > Tibor Digana <[hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=5882181&i=0>> schrieb am
> Di.,
> > > 4. Okt. 2016 um
> > > 02:29 Uhr:
> > >
> > > > Can you simplify and speed up writing integration tests in the way
> that
> > > you
> > > > would parameterize the existing JUnit 4 testing by adding Maven
> > profiles
> > > > (one default profile and junit5 profile) having another dependencies
> > and
> > > > @RunWith(Parameterized.class)?
> > > > This would be cool because we can have identical assertion
> statements,
> > > > means behavior, for multiple providers.
> > > >
> > >
> > > I was already thinking about this, because right now I'm duplicating a
> > lot
> > > of the code from the ITs. This is definitely a good idea. But right
> know
> > I
> > > don't have a clear view of how we could implement that. Do we just
> share
> > > the test class and work with separate test projects? Or do we want to
> > even
> > > share the test projects and work with profiles in the test project
> pom?
> > >
> > > JUnit 5 also has support for running legacy tests (they call it
> > > "vintage").
> > > To make a complete IT suite, we would have to run all the JUnit 4
> tests
> > > against the JUnit 5 vintage engine as well.
> > >
> > > Lot a work ahead :-)
> > >
> > > Regards,
> > > Benedikt
> > >
> > >
> > > >
> > > > On Mon, Oct 3, 2016 at 7:38 PM, Benedikt Ritter <[hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=5882181&i=1>>
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > now that we have a separate branch for the JUnit 5 support in the
> > > > surefire
> > > > > repo, I'm asking myself how to much things forward. I've added
> some
> > > > > additional IT implementations in my GitHub fork, but they all fail
> > > > because
> > > > > the 5.0.0-M2 release of junit-surefire-provider does not implement
> > the
> > > > > desired features.
> > > > >
> > > > > At this point I'm pretty much blocked: I can not pick up the
> latest
> > > > changes
> > > > > to the JUnit 5 provider, because the JUnit team has not released
> it.
> > > The
> > > > > JUnit team does not push the development of the provider further,
> > > since
> > > > > they don't have integration tests...
> > > > > Right now I think it would be best to start implementing a JUnit 5
> > > > provider
> > > > > ourself in the junit5 branch, so we can add the missing features
> and
> > > have
> > > > > it ready when JUnit 5 reaches GA.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Benedikt
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Cheers
> > > > Tibor
> > > >
> > >
> > >
> > > ------------------------------
> > > If you reply to this email, your message will be added to the
> discussion
> > > below:
> > > http://maven.40175.n5.nabble.com/SUREFIRE-JUnit-5-support-
> > > how-to-move-things-forward-tp5882104p5882181.html
> > > To start a new topic under Maven Developers, email
> > > [hidden email] <http:///user/SendEmail.jtp?type=node&node=5882750&i=2>
> > > To unsubscribe from Maven Developers, click here
> > > <
> > >
> > > .
> > > 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-Parameterized-
> Tests-for-Junit-4-and-Junit-5-Was-SUREFIRE-JUnit-5-support-
> how-to-move-thi-tp5882187.html
> > Sent from the Maven Developers mailing list archive at Nabble.com.
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/Re-SUREFIRE-Parameterized-
> Tests-for-Junit-4-and-Junit-5-Was-SUREFIRE-JUnit-5-support-
> how-to-move-thi-tp5882187p5882750.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-Parameterized-Tests-for-Junit-4-and-Junit-5-Was-SUREFIRE-JUnit-5-support-how-to-move-thi-tp5882187p5882861.html
Sent from the Maven Developers mailing list archive at Nabble.com.

Reply via email to