[GitHub] maven-surefire issue #127: [SUREFIRE-1293] Simplify org.apache.maven.plugin....

[britter]

Github user britter commented on the issue:

https://github.com/apache/maven-surefire/pull/127
  
@Tibor17 fixed checkstyle issues, moved creation of null objects to 
DefaultRepoterFactory and squasched everything into one commit. Hope you like 
it! :-)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-surefire issue #125: Consistently rename JUnit 4.x integration tests

[britter]

Github user britter commented on the issue:

https://github.com/apache/maven-surefire/pull/125
  
@Tibor17 rebased with master.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Cannot build current master.

[Christian Schulte]

Am 10/11/16 um 21:50 schrieb Karl Heinz Marbaise:
> Hi Guillaue,
> 
> On 11/10/16 21:21, Guillaume Boué wrote:
>> Regarding this failure, I think it is caused by a capitalization
>> issue... The test is looking for
>> "missing-artifactid-pluginManagement.xml" (lowercase "i" at artifactid)
>> while the file on disk is called
>> "missing-artifactId-pluginManagement.xml" (uppercase "i"). I don't have
>> the issue on Windows (since I believe it is case insensitive), and don't
>> have a Ubuntu box to test this right now.
>>
>> To me, we just need to change line 647 of DefaultModelValidatorTest to
>> have an uppercase "i" at "artifactId".
> 
> I changed that. Many thanks for your hint...
> 

I tested on Windows and could not reproduce the issue there. On my BSD
laptop it failed. Builds successfully now. Thanks.

Regards,
-- 
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Cannot build current master.

[Karl Heinz Marbaise]

Hi Guillaue,

On 11/10/16 21:21, Guillaume Boué wrote:

Regarding this failure, I think it is caused by a capitalization
issue... The test is looking for
"missing-artifactid-pluginManagement.xml" (lowercase "i" at artifactid)
while the file on disk is called
"missing-artifactId-pluginManagement.xml" (uppercase "i"). I don't have
the issue on Windows (since I believe it is case insensitive), and don't
have a Ubuntu box to test this right now.

To me, we just need to change line 647 of DefaultModelValidatorTest to
have an uppercase "i" at "artifactId".


I changed that. Many thanks for your hint...

Kind regards
Karl Heinz




Guillaume


Le 11/10/2016 à 07:47, Karl Heinz Marbaise a écrit :

Hi,

interesting, cause I couldn't reproduce the issue on my system ..only
the build server shows an test failure...

I need to investigage the reason for that ...cause other tests from
the same folder working...

Are you running on Linux / Mac / Windows ? Java Version?

Kind regards
Karl Heinz

On 11/10/16 01:27, Christian Schulte wrote:

Just updated current master and am getting test failures. Just my local
checkout?

$ env LC_ALL=C git branch
* master
  maven-3.x-next

$ env LC_ALL=C git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

testInvalidArtifactIdInPluginManagement(org.apache.maven.model.validation.DefaultModelValidatorTest)

Time elapsed: 0.04 sec  <<< FAILURE!
junit.framework.AssertionFailedError: missing resource:
/poms/validation/raw-model/missing-artifactid-pluginManagement.xml
at
org.apache.maven.model.validation.DefaultModelValidatorTest.read(DefaultModelValidatorTest.java:46)

at
org.apache.maven.model.validation.DefaultModelValidatorTest.validateRaw(DefaultModelValidatorTest.java:79)

at
org.apache.maven.model.validation.DefaultModelValidatorTest.validateRaw(DefaultModelValidatorTest.java:59)

at
org.apache.maven.model.validation.DefaultModelValidatorTest.testInvalidArtifactIdInPluginManagement(DefaultModelValidatorTest.java:647)


Failed tests:

DefaultModelValidatorTest.testInvalidArtifactIdInPluginManagement:647->validateRaw:59->validateRaw:79->read:46

missing resource:
/poms/validation/raw-model/missing-artifactid-pluginManagement.xml

[INFO] Maven Model Builder  FAILURE [
22.377 s]


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Cannot build current master.

[Guillaume Boué]

Regarding this failure, I think it is caused by a capitalization 
issue... The test is looking for 
"missing-artifactid-pluginManagement.xml" (lowercase "i" at artifactid) 
while the file on disk is called 
"missing-artifactId-pluginManagement.xml" (uppercase "i"). I don't have 
the issue on Windows (since I believe it is case insensitive), and don't 
have a Ubuntu box to test this right now.


To me, we just need to change line 647 of DefaultModelValidatorTest to 
have an uppercase "i" at "artifactId".


Guillaume


Le 11/10/2016 à 07:47, Karl Heinz Marbaise a écrit :

Hi,

interesting, cause I couldn't reproduce the issue on my system ..only 
the build server shows an test failure...


I need to investigage the reason for that ...cause other tests from 
the same folder working...


Are you running on Linux / Mac / Windows ? Java Version?

Kind regards
Karl Heinz

On 11/10/16 01:27, Christian Schulte wrote:

Just updated current master and am getting test failures. Just my local
checkout?

$ env LC_ALL=C git branch
* master
  maven-3.x-next

$ env LC_ALL=C git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

testInvalidArtifactIdInPluginManagement(org.apache.maven.model.validation.DefaultModelValidatorTest) 


Time elapsed: 0.04 sec  <<< FAILURE!
junit.framework.AssertionFailedError: missing resource:
/poms/validation/raw-model/missing-artifactid-pluginManagement.xml
at
org.apache.maven.model.validation.DefaultModelValidatorTest.read(DefaultModelValidatorTest.java:46) 


at
org.apache.maven.model.validation.DefaultModelValidatorTest.validateRaw(DefaultModelValidatorTest.java:79) 


at
org.apache.maven.model.validation.DefaultModelValidatorTest.validateRaw(DefaultModelValidatorTest.java:59) 


at
org.apache.maven.model.validation.DefaultModelValidatorTest.testInvalidArtifactIdInPluginManagement(DefaultModelValidatorTest.java:647) 



Failed tests:

DefaultModelValidatorTest.testInvalidArtifactIdInPluginManagement:647->validateRaw:59->validateRaw:79->read:46 


missing resource:
/poms/validation/raw-model/missing-artifactid-pluginManagement.xml

[INFO] Maven Model Builder  FAILURE [
22.377 s]


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-surefire pull request #126: Make Junit4VersionsIT parameterized

[britter]

Github user britter closed the pull request at:

https://github.com/apache/maven-surefire/pull/126


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-surefire issue #126: Make Junit4VersionsIT parameterized

[britter]

Github user britter commented on the issue:

https://github.com/apache/maven-surefire/pull/126
  
Okay, this is reintegrated. I will fix it in another PR. Thank you!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-surefire issue #127: [SUREFIRE-1293] Simplify org.apache.maven.plugin....

[britter]

Github user britter commented on the issue:

https://github.com/apache/maven-surefire/pull/127
  
Hello @Tibor17, I'll fix the checkstyle violations and squash everything 
into one single commit!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [SUREFIRE] Hangout with Marc Philipp

[Tibor Digana]

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 
wrote:

> We can follow already existing principle and declare JUnit5 version in [1].
> There is already such good example:
>
> 
> ${project.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 
> 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
>> > > acro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYX
>> BhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==>
>> > .
>> > NAML
>> > > 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 thi

Re: [SUREFIRE] Hangout with Marc Philipp

[Tibor Digana]

We can follow already existing principle and declare JUnit5 version in [1].
There is already such good example:


${project.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 
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/
> 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
> >  macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3
> wxNDIxNjZ8LTI4OTQ5MjEwMg==>
> > .
> > NAML
> >  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.

RE: upgrade maven plugin to run with asm 6?

[Martin Gainty]

i find throwing everything in the kitchen sink and hoping all the dishes get 
cleaned doesnt workpick one variable such as maven-plugin-plugin and introduce 
each new version by a point release3.0 causes exception3.1 causes 
exception...3.5 works with asm6 and JDK 1.9
eventually you'll determine which version works with your specific environment 
configuration

ToDo: can someone update README for 3.5 that 3.5 works with JDK1.9 and ASM6?
thanks romainMartin
__ 



> From: rmannibu...@gmail.com
> Date: Mon, 10 Oct 2016 21:04:50 +0200
> Subject: RE: upgrade maven plugin to run with asm 6?
> To: dev@maven.apache.org
> 
> Oh tested 3.4 but missed 3.5. 3.5 solved the issue!
> 
> Thanks!
> 
> Le 10 oct. 2016 20:31, "Martin Gainty"  a écrit :
> >
> >
> >
> >
> > > From: rmannibu...@gmail.com
> > > Date: Mon, 10 Oct 2016 17:07:54 +0200
> > > Subject: Re: upgrade maven plugin to run with asm 6?
> > > To: dev@maven.apache.org
> > >
> > > 2016-10-10 16:54 GMT+02:00 Martin Gainty :
> > >
> > > >
> > > >
> > > >
> > > > > From: rmannibu...@gmail.com
> > > > > Date: Mon, 10 Oct 2016 15:10:33 +0200
> > > > > Subject: upgrade maven plugin to run with asm 6?
> > > > > To: dev@maven.apache.org
> > > > >
> > > > > Hi guys,
> > > > >
> > > > > is there some plans to upgrade maven plugin to asm6 (thinking
> > > > > to maven-plugin-tools-annotations and maven-plugin-plugin and more
> > > > > concretely to DefaultMojoAnnotationsScanner used to generate the
> help
> > > > mojo)?
> > > > >
> > > > > I know there is only the alpha our ATM but I think it would enable
> users
> > > > to
> > > > > start building using asm 6 instead of preventing them to run their
> build
> > > > > and the later upgrade would be smooth.
> > > > MG>craft a q&d test-harness
> > > > MG>switch JAVA to JDK 1.8
> > > > MG>in test-harness substitute in asm-6 into dependency-management of
> > > > parent pom
> > > > MG>mvn package and observe:
> > > > MG>ANY TEST ERRORS ?
> > > > MG>ANY TEST FAILURES?
> > > > MG>is JDKProxy being implemented to implement Interfaces?
> > > > MG>is asm-6 being called to extend subclasses?
> > > > MG>http://stackoverflow.com/questions/10664182/what-is-
> > > > the-difference-between-jdk-dynamic-proxy-and-cglib
> > > > MG>if all of these scenarios pass I think you will have a *convincing
> > > > case* to upgrade asm to 6 in all plugins
> > > > MG>I have a few spare cycles today so let me know if you need any
> > > > assistance
> > > >
> > > >
> > > so concretely I wanted to upgrade
> > > https://github.com/tomitribe/crest/tree/master/crest-maven-plugin to
> asm6
> > > to support java 9 (not sure why you spoke of java 8, typo?) but the side
> > > effect of upgrading it as a dependency of my project was to break the
> > > maven-plugin-plugin. I'm not sure why isolation was broken but I'm very
> > > concerned cause soon we'll upgrade the whole tomee stack to asm 6
> (xbean,
> > > openjpa, cxf, openwebbeans, batchee, tomee itself and probably a few I
> > > forget) and most of them have maven plugins and would break.
> > >
> > > It fails with a NPE in Type.getProxyClass IIRC so maven annotation
> scanner
> > > doesn't work on java 9.
> > MG>JDK 1.9 annotation processor has been "tweaked"
> > MG>http://openjdk.java.net/jeps/217
> > MG>which is the reason why I suggested using the older annotation scanner
> > MG>do we know if error originates from ASM6 upgrade, maven-plugin or
> JDK1.9 that said can you post a bug in JIRA?
> > MG>https://maven.apache.org/issue-tracking.html
> > >
> > > Will be a bit short to help in the ~2 coming weeks but if nothing moved
> > > next month I'll try to hack something up for sure!
> > >
> > >
> > > >
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau  |  Blog
> > > > >  | Old Wordpress Blog
> > > > >  | Github  > > > rmannibucau> |
> > > > > LinkedIn  | Tomitriber
> > > > >  | JavaEE Factory
> > > > > 
> > > >
> >
  

[GitHub] maven-surefire issue #127: [SUREFIRE-1293] Simplify org.apache.maven.plugin....

[Tibor17]

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/127
  
After we are done with all commits, would you be able to safely squash them 
in one single commit?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [SUREFIRE] Hangout with Marc Philipp

[Tibor Digana]

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
> 
> .
> 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.

Re: [SUREFIRE] Parameterized Tests for Junit 4 and Junit 5? (Was: [SUREFIRE] JUnit 5 support - how to move things forward?)

[Tibor Digana]

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]
> > 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  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
> > 
> > and
> > another profile with 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
> >  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] >
> wrote:
> >
> > > Hello Tibor,
> > >
> > > Tibor Digana <[hidden email]
> > > > 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]
> > > >
> > > > 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 i