Re: Welcome Sylwester Lachiewicz to the Apache Maven Team

[Martin Gainty]

wilkommen sylwester

i look forward to reading your jira reports

martin

From: Karl Heinz Marbaise 
Sent: Wednesday, September 5, 2018 1:27 PM
To: Maven Developers List; Sylwester Lachiewicz
Subject: Re: Welcome Sylwester Lachiewicz to the Apache Maven Team

Hi Sylwester,

On 05/09/18 19:20, Sylwester Lachiewicz wrote:
> Hi Everyone,
>
> thank you for so warm welcome - my adventure with helping Maven Project
> began not so long ago, and the more I am more than willing to join you.

Great to hear this...


> We have some work in Jira and a PRs to review - I'm going to verify it.

Yeah we much JIRA's 

 >
And
> I hope The Maven Team in the future with commits.

That was the idea ;-)...


Kind regards
Karl Heinz Marbaise
>
> Best regards
> Sylwester
>
> pon., 3 wrz 2018 o 19:21 użytkownik Tibor Digana 
> napisał:
>
>>   Welcome Sylwester!
>>
>> On Sun, Sep 2, 2018 at 12:58 PM Karl Heinz Marbaise 
>> wrote:
>>
>>> Hi to all,
>>>
>>> On behalf of the Apache Maven PMC I am pleased to announce that
>>> Sylwester Lachiewicz has been voted in as a new Apache Maven committer.
>>>
>>> Sylwester, welcome on board and have a lot of fun!
>>>
>>> Thanks.
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>>
>>
>


Mit freundlichem Gruß
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579
Hauptstrasse 177
52146 Würselen   http://www.soebes.de

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

Re: Server Issue

[Karl Heinz Marbaise]

Hi,

please ask questions about the use / problem etc. on the Maven User list 
not on the developers list...


Kind regards
Karl Heinz Marbaise

On 05/09/18 13:56, Priya Lakshmi wrote:

Hi,

I am trying to download maven dependencies from Eclipse IDE. Unfortunately, I 
am not able to download them, and below is the error message I am getting

Plugin org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M2 or one of its 
dependencies could not be resolved: Failed to read artifact descriptor for 
org.apache.maven.plugins:maven-enforcer-plugin:jar:3.0.0-M2: Could not transfer 
artifact org.apache.maven.plugins:maven-enforcer-plugin:Pom:3.0.0-M2 from/to central 
(http://repo.maven.apache.org/maven2): This is usually a temporary error during 
hostname resolution and means that the local server did not receive a response from 
an authoritative server"


I want to know whether the IP address for the server behind this url is static 
or dynamic? And if it's static is there any way I can get the IP address?

Please note that, I am trying to connect through DNS and I feel it is DNS issue


Thanks
Lakshmi



The content of this email (and any attachment) is confidential. It may also be 
legally privileged or otherwise protected from disclosure.
This email should not be used by anyone who is not an original intended 
recipient, nor may it be copied or disclosed to anyone who is not an original 
intended recipient.

If you have received this email by mistake please notify us by emailing the 
sender, and then delete the email and any copies from your system.

Liability cannot be accepted for statements made which are clearly the sender's 
own and not made on behalf of Network Rail.
Network Rail Infrastructure Limited registered in England and Wales No. 
2904587, registered office Network Rail, 2nd Floor, One Eversholt Street, 
London, NW1 2DN





you know that you are posting on a public email list which is archived 
etc. ?


Kind regards
Karl Heinz Marbaise

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

Re: Server Issue

[Basin Ilya]

Hi Priya.


In Eclipse go to Window > Show View > Other > Genearl > Problems
The "Problems" view will appear.
Find there the error and copy it. The error should contain the full stack trace 
explaining the problem.

Sometimes the Plugin Downloader reports only the short description. In that 
case you can try to temporarily add the plugin as a compile dependency to your 
project.
Last time I checked the "Failed to read artifact descriptor" contained the 
needed info, e.g.:

Caused by: java.net.UnknownHostException


Shot in the dark: perhaps you're using JDK 7, but the Central Maven repo has 
recently switched to TLS 1.2 which is disabled in Java 7 by default. Try to 
launch Eclipse under JDK 8.



05.09.2018 14:56, Priya Lakshmi пишет:
> Hi,
> 
> I am trying to download maven dependencies from Eclipse IDE. Unfortunately, I 
> am not able to download them, and below is the error message I am getting
> 
> Plugin org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M2 or one of its 
> dependencies could not be resolved: Failed to read artifact descriptor for 
> org.apache.maven.plugins:maven-enforcer-plugin:jar:3.0.0-M2: Could not 
> transfer artifact org.apache.maven.plugins:maven-enforcer-plugin:Pom:3.0.0-M2 
> from/to central (http://repo.maven.apache.org/maven2): This is usually a 
> temporary error during hostname resolution and means that the local server 
> did not receive a response from an authoritative server"
> 
> 
> I want to know whether the IP address for the server behind this url is 
> static or dynamic? And if it's static is there any way I can get the IP 
> address?
> 
> Please note that, I am trying to connect through DNS and I feel it is DNS 
> issue
> 
> 
> Thanks
> Lakshmi
> 
> 
>  
> 
> The content of this email (and any attachment) is confidential. It may also 
> be legally privileged or otherwise protected from disclosure. 
> This email should not be used by anyone who is not an original intended 
> recipient, nor may it be copied or disclosed to anyone who is not an original 
> intended recipient. 
> 
> If you have received this email by mistake please notify us by emailing the 
> sender, and then delete the email and any copies from your system. 
> 
> Liability cannot be accepted for statements made which are clearly the 
> sender's own and not made on behalf of Network Rail. 
> Network Rail Infrastructure Limited registered in England and Wales No. 
> 2904587, registered office Network Rail, 2nd Floor, One Eversholt Street, 
> London, NW1 2DN 
> 
> 
> 

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

Re: Welcome Sylwester Lachiewicz to the Apache Maven Team

[Karl Heinz Marbaise]

Hi Sylwester,

On 05/09/18 19:20, Sylwester Lachiewicz wrote:

Hi Everyone,

thank you for so warm welcome - my adventure with helping Maven Project
began not so long ago, and the more I am more than willing to join you.


Great to hear this...


We have some work in Jira and a PRs to review - I'm going to verify it. 


Yeah we much JIRA's 

>
And

I hope The Maven Team in the future with commits.


That was the idea ;-)...


Kind regards
Karl Heinz Marbaise


Best regards
Sylwester

pon., 3 wrz 2018 o 19:21 użytkownik Tibor Digana 
napisał:


  Welcome Sylwester!

On Sun, Sep 2, 2018 at 12:58 PM Karl Heinz Marbaise 
wrote:


Hi to all,

On behalf of the Apache Maven PMC I am pleased to announce that
Sylwester Lachiewicz has been voted in as a new Apache Maven committer.

Sylwester, welcome on board and have a lot of fun!

Thanks.

Kind regards
Karl Heinz Marbaise

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









Mit freundlichem Gruß
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579
Hauptstrasse 177
52146 Würselen   http://www.soebes.de

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

Re: issue with junit 5 integration

[Christian Stein]

On Wed, Sep 5, 2018 at 6:49 PM Tibor Digana  wrote:

> >> Yes but the platform and engine are transitive, right?
> Yes. We can grab the classpath from the forked jvm via Jconsole and we
> should see these artifacts.
>
> @Christian
> what happens when you just add new Engine with another version to the POM's
> dependencies or plugin's dependencies.
> The old version of JUnit5 Engine is overridden?
>
> We should decide which way is not error prone from the users perspective.
> WDYT?
>
>
What happens in Surefire today needs some investigations... I was sure
yesterday
and earlier today, but had to partly revert changes in our sample projects
to actually
force Surefire to find and execute tests. See [1] for the changes I made. I
fear that
now both versions, 1.2.0 and 1.3.0, do land on the classpath now...


[1]
https://github.com/junit-team/junit5-samples/commit/6c81972c691a7d055d895953eda5cefead8dc541


There are two debug statements from Surefire I don't understand. They look
like:

...
[DEBUG] test(compact) classpath:
  test-classes
  classes
  junit-jupiter-api-5.3.0.jar
  apiguardian-api-1.0.0.jar
  opentest4j-1.1.0.jar
  junit-platform-commons-1.3.0.jar
  junit-jupiter-params-5.3.0.jar
  junit-jupiter-engine-5.3.0.jar
  junit-platform-engine-1.3.0.jar
...
T E S T S
...
[DEBUG] boot(compact) classpath:
  surefire-booter-2.22.0.jar
  surefire-api-2.22.0.jar
  surefire-logger-api-2.22.0.jar
  test-classes
  classes
  junit-jupiter-api-5.3.0.jar
  apiguardian-api-1.0.0.jar
  opentest4j-1.1.0.jar
  junit-platform-commons-1.3.0.jar
  junit-jupiter-params-5.3.0.jar
  junit-jupiter-engine-5.3.0.jar
  junit-platform-engine-1.3.0.jar
  surefire-junit-platform-2.22.0.jar
  junit-platform-launcher-1.2.0.jar
  junit-platform-engine-1.2.0.jar
  junit-platform-commons-1.2.0.jar
...

The first one "test" looks good, the second one "boot" doesn't...

You may reproduce it by cloning "
https://github.com/junit-team/junit5-samples;
and running "mvn clean test -X" in "junit5-jupiter-starter-maven".

Now to what should happen:

1. User-defined artifacts always win.
2. Platform and Engines are different products a need to agree on a minimal
Platform version.
3. Platform versions are backwards compatible.
4. The highest Platform version "in the stack" wins.
5. The presence of an API may imply an associated Engine artifact and
version. (Jupiter API -> 99% Jupiter Engine)
6. The presence of an API may imply running a Surefire provider -- but also
could
handled by the JUnit Platform (provider). E.g. seeing TestNG artifact
could mean
that the user wants the JUnit Platform with TestNGine [2] to find and
run tests.

The list is far from complete.

Cheers,
Christian

[2]

Re: Welcome Sylwester Lachiewicz to the Apache Maven Team

[Sylwester Lachiewicz]

Hi Everyone,

thank you for so warm welcome - my adventure with helping Maven Project
began not so long ago, and the more I am more than willing to join you.
We have some work in Jira and a PRs to review - I'm going to verify it. And
I hope The Maven Team in the future with commits.

Best regards
Sylwester

pon., 3 wrz 2018 o 19:21 użytkownik Tibor Digana 
napisał:

>  Welcome Sylwester!
>
> On Sun, Sep 2, 2018 at 12:58 PM Karl Heinz Marbaise 
> wrote:
>
> > Hi to all,
> >
> > On behalf of the Apache Maven PMC I am pleased to announce that
> > Sylwester Lachiewicz has been voted in as a new Apache Maven committer.
> >
> > Sylwester, welcome on board and have a lot of fun!
> >
> > Thanks.
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: issue with junit 5 integration

[Tibor Digana]

>> Yes but the platform and engine are transitive, right?
Yes. We can grab the classpath from the forked jvm via Jconsole and we
should see these artifacts.

@Christian
what happens when you just add new Engine with another version to the POM's
dependencies or plugin's dependencies.
The old version of JUnit5 Engine is overridden?

We should decide which way is not error prone from the users perspective.
WDYT?

On Wed, Sep 5, 2018 at 6:23 PM Romain Manni-Bucau 
wrote:

> Le mer. 5 sept. 2018 18:20, Tibor Digana
>  a écrit :
>
> > Romain, that link in Resolver means that our Provider has transitive
> > dependencies. This Surefire's Platform Provider + it's dependencies. Not
> > the JUnit5's provider.
> >
>
> Yes but the platform and engine are transitive, right?
>
>
> Adding engine with another version makes sense to me in current situation.
> > It's similar to what we are doing when we add junit:junit:4.12.
> > My question is whether the Engine should have scope=provided in
> Surefire's
> > Provider in the future and the user is forced to add it anyway in his
> POM.
> >
>
> I wouldnt force but ensure it is made easy or even transparent based on the
> api - platform and engines are discoverable for now, can become tricky for
> the platform later but let's tackle it when it arrives.
>
>
> > On Wed, Sep 5, 2018 at 9:16 AM Romain Manni-Bucau  >
> > wrote:
> >
> > > Me too but
> > >
> > >
> >
> https://github.com/apache/maven-surefire/blob/d88ce541f3ba78a12422bdfa35c98cfb5783f9ea/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/SurefireDependencyResolver.java#L142
> > > only handles a single artifact whereas junit5 relies on N > 1 artifacts
> > for
> > > its stack.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le mer. 5 sept. 2018 à 08:23, Dan Tran  a écrit :
> > >
> > > > " surefire provider forces 1.2.0" this is not good :-)  i thought
> > > surefire
> > > > auto detect first one available in classpath
> > > >
> > > > On Tue, Sep 4, 2018 at 11:06 PM Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > > > jupiter ;)
> > > > >
> > > > > junit 5 is not jupiter but platform+ engine*s* so it must detect
> the
> > > full
> > > > > stack and not just the default. A first step can be to detect
> > > > > platform+jupiter+engine but I guess we will get spock, cucumber etc
> > > > engine
> > > > > quickly so being generic can be worth it. In my case I have
> > > > vintage-engine
> > > > > - cause i have junit4 and junit5 extensions and it is broken cause
> > > > vintage
> > > > > uses platform method of the 1.3.0 and the surefire provider forces
> > > 1.2.0.
> > > > >
> > > > > In my proposal, the project dependencies (likely scope test on user
> > > side
> > > > or
> > > > > compile for engine/extension writers) is used and the plugin can
> > > > > override/force some dependencies if needed. Alternative surefire
> > could
> > > > get
> > > > > a specific config for that, not sure it does worth it.
> > > > >
> > > > > Hope it is clearer.
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau  |  Blog
> > > > >  | Old Blog
> > > > >  | Github <
> > > > > https://github.com/rmannibucau> |
> > > > > LinkedIn  | Book
> > > > > <
> > > > >
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > >
> > > > >
> > > > >
> > > > > Le mer. 5 sept. 2018 à 07:41, Dan Tran  a
> écrit :
> > > > >
> > > > > > Odd, I am under impression  surefire auto detect
> > > junit-jupiter-engine
> > > > > at
> > > > > > runtime
> > > > > >
> > > > > > am I missing something?
> > > > > >
> > > > > > -D
> > > > > >
> > > > > > On Tue, Sep 4, 2018 at 10:08 PM Romain Manni-Bucau <
> > > > > rmannibu...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > It does _NOT_ work and as mentionned you can test on meecrowave
> > > > trying
> > > > > to
> > > > > > > upgrade the version in junit module.
> > > > > > >
> > > > > > > The test classpath build ignores project and plugin
> dependencies.
> > > It
> > > > > > faked
> > > > > > > working until 5.3.0-RC1 cause no breakage was visible.
> > > > > > >
> > > > > > > When testing, dont forget to use jupiter, vintage engines +
> > > platform
> > > > > > stack,
> > > > > > > otherwise code is compatible with 1.2 which gets loaded. The
> doc
> > > > > ignores
> > > > > > > the platform and vintage engine and guess it was not tested at
> > all
> > > > > > checking
> > > > > > > the code ;). Not a 

Re: issue with junit 5 integration

[Romain Manni-Bucau]

Le mer. 5 sept. 2018 18:20, Tibor Digana
 a écrit :

> Romain, that link in Resolver means that our Provider has transitive
> dependencies. This Surefire's Platform Provider + it's dependencies. Not
> the JUnit5's provider.
>

Yes but the platform and engine are transitive, right?


Adding engine with another version makes sense to me in current situation.
> It's similar to what we are doing when we add junit:junit:4.12.
> My question is whether the Engine should have scope=provided in Surefire's
> Provider in the future and the user is forced to add it anyway in his POM.
>

I wouldnt force but ensure it is made easy or even transparent based on the
api - platform and engines are discoverable for now, can become tricky for
the platform later but let's tackle it when it arrives.


> On Wed, Sep 5, 2018 at 9:16 AM Romain Manni-Bucau 
> wrote:
>
> > Me too but
> >
> >
> https://github.com/apache/maven-surefire/blob/d88ce541f3ba78a12422bdfa35c98cfb5783f9ea/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/SurefireDependencyResolver.java#L142
> > only handles a single artifact whereas junit5 relies on N > 1 artifacts
> for
> > its stack.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mer. 5 sept. 2018 à 08:23, Dan Tran  a écrit :
> >
> > > " surefire provider forces 1.2.0" this is not good :-)  i thought
> > surefire
> > > auto detect first one available in classpath
> > >
> > > On Tue, Sep 4, 2018 at 11:06 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > jupiter ;)
> > > >
> > > > junit 5 is not jupiter but platform+ engine*s* so it must detect the
> > full
> > > > stack and not just the default. A first step can be to detect
> > > > platform+jupiter+engine but I guess we will get spock, cucumber etc
> > > engine
> > > > quickly so being generic can be worth it. In my case I have
> > > vintage-engine
> > > > - cause i have junit4 and junit5 extensions and it is broken cause
> > > vintage
> > > > uses platform method of the 1.3.0 and the surefire provider forces
> > 1.2.0.
> > > >
> > > > In my proposal, the project dependencies (likely scope test on user
> > side
> > > or
> > > > compile for engine/extension writers) is used and the plugin can
> > > > override/force some dependencies if needed. Alternative surefire
> could
> > > get
> > > > a specific config for that, not sure it does worth it.
> > > >
> > > > Hope it is clearer.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn  | Book
> > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > Le mer. 5 sept. 2018 à 07:41, Dan Tran  a écrit :
> > > >
> > > > > Odd, I am under impression  surefire auto detect
> > junit-jupiter-engine
> > > > at
> > > > > runtime
> > > > >
> > > > > am I missing something?
> > > > >
> > > > > -D
> > > > >
> > > > > On Tue, Sep 4, 2018 at 10:08 PM Romain Manni-Bucau <
> > > > rmannibu...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > It does _NOT_ work and as mentionned you can test on meecrowave
> > > trying
> > > > to
> > > > > > upgrade the version in junit module.
> > > > > >
> > > > > > The test classpath build ignores project and plugin dependencies.
> > It
> > > > > faked
> > > > > > working until 5.3.0-RC1 cause no breakage was visible.
> > > > > >
> > > > > > When testing, dont forget to use jupiter, vintage engines +
> > platform
> > > > > stack,
> > > > > > otherwise code is compatible with 1.2 which gets loaded. The doc
> > > > ignores
> > > > > > the platform and vintage engine and guess it was not tested at
> all
> > > > > checking
> > > > > > the code ;). Not a big deal since it is a "first" release but we
> > > should
> > > > > be
> > > > > > ablz to get it fixed quickly.
> > > > > >
> > > > > >
> > > > > > Le mar. 4 sept. 2018 23:51, Olivier Lamy  a
> > écrit
> > > :
> > > > > >
> > > > > > > Ok perso I don't mind (it just need to be documented)
> > > > > > > But the issue is: users are used to simply upgrade their junit
> > > > > > dependency.
> > > > > > >
> > > > > > >
> > > > > > > On Wed, 5 Sep 2018 at 07:37, Christian Stein <
> sormu...@gmail.com
> > >
> > > > > wrote:
> > > > > > >
> > > > > > > > No, it works with Surefire 2.22.0 and JUnit 5.3.
> > > > > > > >
> > > > > > > > Just add (or move) the test-runtime dependencies to the
> > Surefire
> > > > > plugin
> > > > > > > > 

Re: issue with junit 5 integration

[Tibor Digana]

(Sorry, I had to re-send my email from apache.org)
Romain, that link in Resolver means that our Provider has transitive
dependencies. This Surefire's Platform Provider + it's dependencies. Not
the JUnit5's provider.
Adding engine with another version makes sense to me in current situation.
It's similar to what we are doing when we add junit:junit:4.12.
My question is whether the Engine should have scope=provided in Surefire's
Provider in the future and the user is forced to add it anyway in his POM.

On Wed, Sep 5, 2018 at 9:16 AM Romain Manni-Bucau 
wrote:

> Me too but
>
> https://github.com/apache/maven-surefire/blob/d88ce541f3ba78a12422bdfa35c98cfb5783f9ea/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/SurefireDependencyResolver.java#L142
> only handles a single artifact whereas junit5 relies on N > 1 artifacts for
> its stack.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 5 sept. 2018 à 08:23, Dan Tran  a écrit :
>
> > " surefire provider forces 1.2.0" this is not good :-)  i thought
> surefire
> > auto detect first one available in classpath
> >
> > On Tue, Sep 4, 2018 at 11:06 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > jupiter ;)
> > >
> > > junit 5 is not jupiter but platform+ engine*s* so it must detect the
> full
> > > stack and not just the default. A first step can be to detect
> > > platform+jupiter+engine but I guess we will get spock, cucumber etc
> > engine
> > > quickly so being generic can be worth it. In my case I have
> > vintage-engine
> > > - cause i have junit4 and junit5 extensions and it is broken cause
> > vintage
> > > uses platform method of the 1.3.0 and the surefire provider forces
> 1.2.0.
> > >
> > > In my proposal, the project dependencies (likely scope test on user
> side
> > or
> > > compile for engine/extension writers) is used and the plugin can
> > > override/force some dependencies if needed. Alternative surefire could
> > get
> > > a specific config for that, not sure it does worth it.
> > >
> > > Hope it is clearer.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le mer. 5 sept. 2018 à 07:41, Dan Tran  a écrit :
> > >
> > > > Odd, I am under impression  surefire auto detect
> junit-jupiter-engine
> > > at
> > > > runtime
> > > >
> > > > am I missing something?
> > > >
> > > > -D
> > > >
> > > > On Tue, Sep 4, 2018 at 10:08 PM Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > > > It does _NOT_ work and as mentionned you can test on meecrowave
> > trying
> > > to
> > > > > upgrade the version in junit module.
> > > > >
> > > > > The test classpath build ignores project and plugin dependencies.
> It
> > > > faked
> > > > > working until 5.3.0-RC1 cause no breakage was visible.
> > > > >
> > > > > When testing, dont forget to use jupiter, vintage engines +
> platform
> > > > stack,
> > > > > otherwise code is compatible with 1.2 which gets loaded. The doc
> > > ignores
> > > > > the platform and vintage engine and guess it was not tested at all
> > > > checking
> > > > > the code ;). Not a big deal since it is a "first" release but we
> > should
> > > > be
> > > > > ablz to get it fixed quickly.
> > > > >
> > > > >
> > > > > Le mar. 4 sept. 2018 23:51, Olivier Lamy  a
> écrit
> > :
> > > > >
> > > > > > Ok perso I don't mind (it just need to be documented)
> > > > > > But the issue is: users are used to simply upgrade their junit
> > > > > dependency.
> > > > > >
> > > > > >
> > > > > > On Wed, 5 Sep 2018 at 07:37, Christian Stein  >
> > > > wrote:
> > > > > >
> > > > > > > No, it works with Surefire 2.22.0 and JUnit 5.3.
> > > > > > >
> > > > > > > Just add (or move) the test-runtime dependencies to the
> Surefire
> > > > plugin
> > > > > > > element:
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > >   
> > > > > > >   
> > > > > > >  maven-surefire-plugin
> > > > > > >  2.22.0
> > > > > > >  
> > > > > > >
> > > > > > >org.junit.jupiter
> > > > > > >
> > > junit-jupiter-engine
> > > > > > >5.3.0
> > > > > > >
> > > > > > >  
> > > > > > >   
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > >
> > > > > > > Just checking our sample builds over at JUnit 

Re: issue with junit 5 integration

[Tibor Digana]

Romain, that link in Resolver means that our Provider has transitive
dependencies. This Surefire's Platform Provider + it's dependencies. Not
the JUnit5's provider.
Adding engine with another version makes sense to me in current situation.
It's similar to what we are doing when we add junit:junit:4.12.
My question is whether the Engine should have scope=provided in Surefire's
Provider in the future and the user is forced to add it anyway in his POM.

On Wed, Sep 5, 2018 at 9:16 AM Romain Manni-Bucau 
wrote:

> Me too but
>
> https://github.com/apache/maven-surefire/blob/d88ce541f3ba78a12422bdfa35c98cfb5783f9ea/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/SurefireDependencyResolver.java#L142
> only handles a single artifact whereas junit5 relies on N > 1 artifacts for
> its stack.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 5 sept. 2018 à 08:23, Dan Tran  a écrit :
>
> > " surefire provider forces 1.2.0" this is not good :-)  i thought
> surefire
> > auto detect first one available in classpath
> >
> > On Tue, Sep 4, 2018 at 11:06 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > jupiter ;)
> > >
> > > junit 5 is not jupiter but platform+ engine*s* so it must detect the
> full
> > > stack and not just the default. A first step can be to detect
> > > platform+jupiter+engine but I guess we will get spock, cucumber etc
> > engine
> > > quickly so being generic can be worth it. In my case I have
> > vintage-engine
> > > - cause i have junit4 and junit5 extensions and it is broken cause
> > vintage
> > > uses platform method of the 1.3.0 and the surefire provider forces
> 1.2.0.
> > >
> > > In my proposal, the project dependencies (likely scope test on user
> side
> > or
> > > compile for engine/extension writers) is used and the plugin can
> > > override/force some dependencies if needed. Alternative surefire could
> > get
> > > a specific config for that, not sure it does worth it.
> > >
> > > Hope it is clearer.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le mer. 5 sept. 2018 à 07:41, Dan Tran  a écrit :
> > >
> > > > Odd, I am under impression  surefire auto detect
> junit-jupiter-engine
> > > at
> > > > runtime
> > > >
> > > > am I missing something?
> > > >
> > > > -D
> > > >
> > > > On Tue, Sep 4, 2018 at 10:08 PM Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > > > It does _NOT_ work and as mentionned you can test on meecrowave
> > trying
> > > to
> > > > > upgrade the version in junit module.
> > > > >
> > > > > The test classpath build ignores project and plugin dependencies.
> It
> > > > faked
> > > > > working until 5.3.0-RC1 cause no breakage was visible.
> > > > >
> > > > > When testing, dont forget to use jupiter, vintage engines +
> platform
> > > > stack,
> > > > > otherwise code is compatible with 1.2 which gets loaded. The doc
> > > ignores
> > > > > the platform and vintage engine and guess it was not tested at all
> > > > checking
> > > > > the code ;). Not a big deal since it is a "first" release but we
> > should
> > > > be
> > > > > ablz to get it fixed quickly.
> > > > >
> > > > >
> > > > > Le mar. 4 sept. 2018 23:51, Olivier Lamy  a
> écrit
> > :
> > > > >
> > > > > > Ok perso I don't mind (it just need to be documented)
> > > > > > But the issue is: users are used to simply upgrade their junit
> > > > > dependency.
> > > > > >
> > > > > >
> > > > > > On Wed, 5 Sep 2018 at 07:37, Christian Stein  >
> > > > wrote:
> > > > > >
> > > > > > > No, it works with Surefire 2.22.0 and JUnit 5.3.
> > > > > > >
> > > > > > > Just add (or move) the test-runtime dependencies to the
> Surefire
> > > > plugin
> > > > > > > element:
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > >   
> > > > > > >   
> > > > > > >  maven-surefire-plugin
> > > > > > >  2.22.0
> > > > > > >  
> > > > > > >
> > > > > > >org.junit.jupiter
> > > > > > >
> > > junit-jupiter-engine
> > > > > > >5.3.0
> > > > > > >
> > > > > > >  
> > > > > > >   
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > >
> > > > > > > Just checking our sample builds over at JUnit 5. Which do _NOT_
> > do
> > > > this
> > > > > > at

Server Issue

[Priya Lakshmi]

Hi,

I am trying to download maven dependencies from Eclipse IDE. Unfortunately, I 
am not able to download them, and below is the error message I am getting

Plugin org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M2 or one of its 
dependencies could not be resolved: Failed to read artifact descriptor for 
org.apache.maven.plugins:maven-enforcer-plugin:jar:3.0.0-M2: Could not transfer 
artifact org.apache.maven.plugins:maven-enforcer-plugin:Pom:3.0.0-M2 from/to 
central (http://repo.maven.apache.org/maven2): This is usually a temporary 
error during hostname resolution and means that the local server did not 
receive a response from an authoritative server"


I want to know whether the IP address for the server behind this url is static 
or dynamic? And if it's static is there any way I can get the IP address?

Please note that, I am trying to connect through DNS and I feel it is DNS issue


Thanks
Lakshmi


 

The content of this email (and any attachment) is confidential. It may also be 
legally privileged or otherwise protected from disclosure. 
This email should not be used by anyone who is not an original intended 
recipient, nor may it be copied or disclosed to anyone who is not an original 
intended recipient. 

If you have received this email by mistake please notify us by emailing the 
sender, and then delete the email and any copies from your system. 

Liability cannot be accepted for statements made which are clearly the sender's 
own and not made on behalf of Network Rail. 
Network Rail Infrastructure Limited registered in England and Wales No. 
2904587, registered office Network Rail, 2nd Floor, One Eversholt Street, 
London, NW1 2DN 

Re: issue with junit 5 integration

[Christian Stein]

So. Initial results are in.

Setting only: 3.0

...leads to the exception Romain reported. Version 1.2.0 of the Platform is
resolved.

Sorting out the test compile- and runtime dependencies fixes the issue:
See  https://github.com/apache/meecrowave/pull/11 for details.

Now, making Surefire better:

1. Document this setup, split API and platform/engine dependencies.
2. Make Surefire smarter to resolve the correct runtime deps when only API
deps are present.


On Wed, Sep 5, 2018 at 10:33 AM Romain Manni-Bucau 
wrote:

> +1
>
> Tibor got a good point noticing that we use scope provided for some junit
> artifacts which can impact the way the classpath is built.
>
>

Re: issue with junit 5 integration

[Romain Manni-Bucau]

+1

Tibor got a good point noticing that we use scope provided for some junit
artifacts which can impact the way the classpath is built.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 5 sept. 2018 à 10:31, Christian Stein  a écrit :

> On Wed, Sep 5, 2018 at 10:22 AM Romain Manni-Bucau 
> wrote:
>
> > From what I saw in the code the surefire provider artifact is resolved to
> > ...
>
>
> So, specifying that artifact in your setup (explicit or implicit) will lead
> to the correct version
> to be loaded. See the integration tests in Surefire, JUnit 5 sample
> projects, Spring Boot, et al.
>
> ... therefore it ignores the project overrides without my patch.
>
>
> Which is an improvement! And Surefire needs such a logic. I did something
> similar here:
>
> https://github.com/sormuras/junit-platform-maven-plugin/blob/05b7e3ae521ccb7f71d00ccd532523a99a9b6dfc/src/main/java/de/sormuras/junit/platform/maven/plugin/Resolver.java#L87-L116
>
> So, my plan is:
>
> 1. Check meecrowave configuration if it is possible to get it running with
> 2.22.0 and 5.3
> 2. Improve Surefire
>

Re: issue with junit 5 integration

[Christian Stein]

On Wed, Sep 5, 2018 at 10:22 AM Romain Manni-Bucau 
wrote:

> From what I saw in the code the surefire provider artifact is resolved to
> ...


So, specifying that artifact in your setup (explicit or implicit) will lead
to the correct version
to be loaded. See the integration tests in Surefire, JUnit 5 sample
projects, Spring Boot, et al.

... therefore it ignores the project overrides without my patch.


Which is an improvement! And Surefire needs such a logic. I did something
similar here:
https://github.com/sormuras/junit-platform-maven-plugin/blob/05b7e3ae521ccb7f71d00ccd532523a99a9b6dfc/src/main/java/de/sormuras/junit/platform/maven/plugin/Resolver.java#L87-L116

So, my plan is:

1. Check meecrowave configuration if it is possible to get it running with
2.22.0 and 5.3
2. Improve Surefire

Re: issue with junit 5 integration

[Romain Manni-Bucau]

>From what I saw in the code the surefire provider artifact is resolved to
build the classpath ignoring the project configuration (it is just an
artifact resolution) and therefore it ignores the project overrides without
my patch.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 5 sept. 2018 à 10:14, Stephane Nicoll  a
écrit :

> I am more interested to understand what is particular in that project that
> exhibits an issue we don't seem to be facing. That thread is phrased in
> such a way that it is a general problem and I'd like a confirmation of that
> as it may impact Spring Boot (amongst other things)
>
> Thanks,
> S.
>
>
> On Wed, Sep 5, 2018 at 10:13 AM Romain Manni-Bucau 
> wrote:
>
> > @Stephane: you can clone https://github.com/apache/meecrowave/tree/trunk
> > and change the version in the junit pom (
> > https://github.com/apache/meecrowave/blob/trunk/meecrowave-junit/pom.xml
> ),
> > it will fail then
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mer. 5 sept. 2018 à 10:07, Stephane Nicoll  >
> > a
> > écrit :
> >
> > > How do I reproduce this problem concretely? Having to specify a
> > dependency
> > > in surefire is not an option for us as we want the JUnit5 provider to
> be
> > > detected automatically.
> > >
> > > I've upgraded a Spring Boot project to use 5.3.0 and I don't see any
> > > problem.
> > >
> > > Thanks,
> > > S.
> > >
> > >
> > > On Tue, Sep 4, 2018 at 10:46 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > Hi guys,
> > > >
> > > > Jira seems down so sending a mail.
> > > >
> > > > I wanted to upgrade Meecrowave to JUnit 5.3 since it is out but I
> > > realized
> > > > the way surefire provider was developped for JUnit 5 was forcing the
> > > > junit-platform-engine even adding it manually in the test
> dependencies
> > or
> > > > plugin dependencies.
> > > >
> > > > Side note: I didn't investigated other providers but I guess it is
> the
> > > > exact same but the API breakage are happening less often.
> > > >
> > > > I therefore created a PR to fix that ->
> > > > https://github.com/apache/maven-surefire/pull/193
> > > >
> > > > Note: I didn't upgrade the JUnit 5 version in the same release but it
> > > > should probably be done too in another commit/PR.
> > > >
> > > > I wonder if you have release plans which could include this. In terms
> > of
> > > > issues I have in mind the other thing about JUnit 5 which would be
> > great
> > > to
> > > > add is the support for display names instead of using the class+test
> > > names
> > > > in the logs and reports but this is less mandatory than previous one
> > > which
> > > > fails with a NoSuchMethod error when using vintage engine.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn  | Book
> > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > >
> >
>

Re: issue with junit 5 integration

[Stephane Nicoll]

I am more interested to understand what is particular in that project that
exhibits an issue we don't seem to be facing. That thread is phrased in
such a way that it is a general problem and I'd like a confirmation of that
as it may impact Spring Boot (amongst other things)

Thanks,
S.


On Wed, Sep 5, 2018 at 10:13 AM Romain Manni-Bucau 
wrote:

> @Stephane: you can clone https://github.com/apache/meecrowave/tree/trunk
> and change the version in the junit pom (
> https://github.com/apache/meecrowave/blob/trunk/meecrowave-junit/pom.xml),
> it will fail then
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 5 sept. 2018 à 10:07, Stephane Nicoll 
> a
> écrit :
>
> > How do I reproduce this problem concretely? Having to specify a
> dependency
> > in surefire is not an option for us as we want the JUnit5 provider to be
> > detected automatically.
> >
> > I've upgraded a Spring Boot project to use 5.3.0 and I don't see any
> > problem.
> >
> > Thanks,
> > S.
> >
> >
> > On Tue, Sep 4, 2018 at 10:46 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Hi guys,
> > >
> > > Jira seems down so sending a mail.
> > >
> > > I wanted to upgrade Meecrowave to JUnit 5.3 since it is out but I
> > realized
> > > the way surefire provider was developped for JUnit 5 was forcing the
> > > junit-platform-engine even adding it manually in the test dependencies
> or
> > > plugin dependencies.
> > >
> > > Side note: I didn't investigated other providers but I guess it is the
> > > exact same but the API breakage are happening less often.
> > >
> > > I therefore created a PR to fix that ->
> > > https://github.com/apache/maven-surefire/pull/193
> > >
> > > Note: I didn't upgrade the JUnit 5 version in the same release but it
> > > should probably be done too in another commit/PR.
> > >
> > > I wonder if you have release plans which could include this. In terms
> of
> > > issues I have in mind the other thing about JUnit 5 which would be
> great
> > to
> > > add is the support for display names instead of using the class+test
> > names
> > > in the logs and reports but this is less mandatory than previous one
> > which
> > > fails with a NoSuchMethod error when using vintage engine.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> >
>

Re: issue with junit 5 integration

[Romain Manni-Bucau]

@Stephane: you can clone https://github.com/apache/meecrowave/tree/trunk
and change the version in the junit pom (
https://github.com/apache/meecrowave/blob/trunk/meecrowave-junit/pom.xml),
it will fail then

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 5 sept. 2018 à 10:07, Stephane Nicoll  a
écrit :

> How do I reproduce this problem concretely? Having to specify a dependency
> in surefire is not an option for us as we want the JUnit5 provider to be
> detected automatically.
>
> I've upgraded a Spring Boot project to use 5.3.0 and I don't see any
> problem.
>
> Thanks,
> S.
>
>
> On Tue, Sep 4, 2018 at 10:46 PM Romain Manni-Bucau 
> wrote:
>
> > Hi guys,
> >
> > Jira seems down so sending a mail.
> >
> > I wanted to upgrade Meecrowave to JUnit 5.3 since it is out but I
> realized
> > the way surefire provider was developped for JUnit 5 was forcing the
> > junit-platform-engine even adding it manually in the test dependencies or
> > plugin dependencies.
> >
> > Side note: I didn't investigated other providers but I guess it is the
> > exact same but the API breakage are happening less often.
> >
> > I therefore created a PR to fix that ->
> > https://github.com/apache/maven-surefire/pull/193
> >
> > Note: I didn't upgrade the JUnit 5 version in the same release but it
> > should probably be done too in another commit/PR.
> >
> > I wonder if you have release plans which could include this. In terms of
> > issues I have in mind the other thing about JUnit 5 which would be great
> to
> > add is the support for display names instead of using the class+test
> names
> > in the logs and reports but this is less mandatory than previous one
> which
> > fails with a NoSuchMethod error when using vintage engine.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
>

Re: issue with junit 5 integration

[Christian Stein]

On Wed, Sep 5, 2018 at 10:07 AM Stephane Nicoll 
wrote:

> How do I reproduce this problem concretely? Having to specify a dependency
> in surefire is not an option for us as we want the JUnit5 provider to be
> detected automatically.
>
> I've upgraded a Spring Boot project to use 5.3.0 and I don't see any
> problem.
>
>
That's my point: I'm not saying the current implementation is perfect and
that
can't be improved, but there are successful migrated projects that work with
Surefire 2.22.0 and JUnit 5.3 "flawlessly".

Romain is pointing to "meecrowave":
https://twitter.com/rmannibucau/status/1037238234915528704

Looking into the "pom.xml" there right now.

Re: issue with junit 5 integration

[Stephane Nicoll]

How do I reproduce this problem concretely? Having to specify a dependency
in surefire is not an option for us as we want the JUnit5 provider to be
detected automatically.

I've upgraded a Spring Boot project to use 5.3.0 and I don't see any
problem.

Thanks,
S.


On Tue, Sep 4, 2018 at 10:46 PM Romain Manni-Bucau 
wrote:

> Hi guys,
>
> Jira seems down so sending a mail.
>
> I wanted to upgrade Meecrowave to JUnit 5.3 since it is out but I realized
> the way surefire provider was developped for JUnit 5 was forcing the
> junit-platform-engine even adding it manually in the test dependencies or
> plugin dependencies.
>
> Side note: I didn't investigated other providers but I guess it is the
> exact same but the API breakage are happening less often.
>
> I therefore created a PR to fix that ->
> https://github.com/apache/maven-surefire/pull/193
>
> Note: I didn't upgrade the JUnit 5 version in the same release but it
> should probably be done too in another commit/PR.
>
> I wonder if you have release plans which could include this. In terms of
> issues I have in mind the other thing about JUnit 5 which would be great to
> add is the support for display names instead of using the class+test names
> in the logs and reports but this is less mandatory than previous one which
> fails with a NoSuchMethod error when using vintage engine.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>

Re: issue with junit 5 integration

[Romain Manni-Bucau]

Me too but
https://github.com/apache/maven-surefire/blob/d88ce541f3ba78a12422bdfa35c98cfb5783f9ea/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/SurefireDependencyResolver.java#L142
only handles a single artifact whereas junit5 relies on N > 1 artifacts for
its stack.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 5 sept. 2018 à 08:23, Dan Tran  a écrit :

> " surefire provider forces 1.2.0" this is not good :-)  i thought surefire
> auto detect first one available in classpath
>
> On Tue, Sep 4, 2018 at 11:06 PM Romain Manni-Bucau 
> wrote:
>
> > jupiter ;)
> >
> > junit 5 is not jupiter but platform+ engine*s* so it must detect the full
> > stack and not just the default. A first step can be to detect
> > platform+jupiter+engine but I guess we will get spock, cucumber etc
> engine
> > quickly so being generic can be worth it. In my case I have
> vintage-engine
> > - cause i have junit4 and junit5 extensions and it is broken cause
> vintage
> > uses platform method of the 1.3.0 and the surefire provider forces 1.2.0.
> >
> > In my proposal, the project dependencies (likely scope test on user side
> or
> > compile for engine/extension writers) is used and the plugin can
> > override/force some dependencies if needed. Alternative surefire could
> get
> > a specific config for that, not sure it does worth it.
> >
> > Hope it is clearer.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mer. 5 sept. 2018 à 07:41, Dan Tran  a écrit :
> >
> > > Odd, I am under impression  surefire auto detect  junit-jupiter-engine
> > at
> > > runtime
> > >
> > > am I missing something?
> > >
> > > -D
> > >
> > > On Tue, Sep 4, 2018 at 10:08 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > It does _NOT_ work and as mentionned you can test on meecrowave
> trying
> > to
> > > > upgrade the version in junit module.
> > > >
> > > > The test classpath build ignores project and plugin dependencies. It
> > > faked
> > > > working until 5.3.0-RC1 cause no breakage was visible.
> > > >
> > > > When testing, dont forget to use jupiter, vintage engines + platform
> > > stack,
> > > > otherwise code is compatible with 1.2 which gets loaded. The doc
> > ignores
> > > > the platform and vintage engine and guess it was not tested at all
> > > checking
> > > > the code ;). Not a big deal since it is a "first" release but we
> should
> > > be
> > > > ablz to get it fixed quickly.
> > > >
> > > >
> > > > Le mar. 4 sept. 2018 23:51, Olivier Lamy  a écrit
> :
> > > >
> > > > > Ok perso I don't mind (it just need to be documented)
> > > > > But the issue is: users are used to simply upgrade their junit
> > > > dependency.
> > > > >
> > > > >
> > > > > On Wed, 5 Sep 2018 at 07:37, Christian Stein 
> > > wrote:
> > > > >
> > > > > > No, it works with Surefire 2.22.0 and JUnit 5.3.
> > > > > >
> > > > > > Just add (or move) the test-runtime dependencies to the Surefire
> > > plugin
> > > > > > element:
> > > > > >
> > > > > > 
> > > > > >
> > > > > >   
> > > > > >   
> > > > > >  maven-surefire-plugin
> > > > > >  2.22.0
> > > > > >  
> > > > > >
> > > > > >org.junit.jupiter
> > > > > >
> > junit-jupiter-engine
> > > > > >5.3.0
> > > > > >
> > > > > >  
> > > > > >   
> > > > > >
> > > > > > 
> > > > > >
> > > > > >
> > > > > > Just checking our sample builds over at JUnit 5. Which do _NOT_
> do
> > > this
> > > > > at
> > > > > > the moment.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Sep 4, 2018 at 11:32 PM Olivier Lamy 
> > > wrote:
> > > > > >
> > > > > > > Hi
> > > > > > > very embarrassing issue which probably worth a quick release!
> > > > > > > Can you create a jira?
> > > > > > > As junit 5.3.0 has just been released,  I might be happy to cut
> > > > 2.22.1
> > > > > > very
> > > > > > > quickly with only this fix.
> > > > > > > others wdyt?
> > > > > > >
> > > > > > >
> > > > > > > On Wed, 5 Sep 2018 at 06:46, Romain Manni-Bucau <
> > > > rmannibu...@gmail.com
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi guys,
> > > > > > > >
> > > > > > > > Jira seems down so sending a mail.
> > > > > > > >
> > > > > > > > I wanted to upgrade Meecrowave to JUnit 5.3 since it is out
> > but I
> > > > > 

Re: issue with junit 5 integration

[Dan Tran]

" surefire provider forces 1.2.0" this is not good :-)  i thought surefire
auto detect first one available in classpath

On Tue, Sep 4, 2018 at 11:06 PM Romain Manni-Bucau 
wrote:

> jupiter ;)
>
> junit 5 is not jupiter but platform+ engine*s* so it must detect the full
> stack and not just the default. A first step can be to detect
> platform+jupiter+engine but I guess we will get spock, cucumber etc engine
> quickly so being generic can be worth it. In my case I have vintage-engine
> - cause i have junit4 and junit5 extensions and it is broken cause vintage
> uses platform method of the 1.3.0 and the surefire provider forces 1.2.0.
>
> In my proposal, the project dependencies (likely scope test on user side or
> compile for engine/extension writers) is used and the plugin can
> override/force some dependencies if needed. Alternative surefire could get
> a specific config for that, not sure it does worth it.
>
> Hope it is clearer.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 5 sept. 2018 à 07:41, Dan Tran  a écrit :
>
> > Odd, I am under impression  surefire auto detect  junit-jupiter-engine
> at
> > runtime
> >
> > am I missing something?
> >
> > -D
> >
> > On Tue, Sep 4, 2018 at 10:08 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > It does _NOT_ work and as mentionned you can test on meecrowave trying
> to
> > > upgrade the version in junit module.
> > >
> > > The test classpath build ignores project and plugin dependencies. It
> > faked
> > > working until 5.3.0-RC1 cause no breakage was visible.
> > >
> > > When testing, dont forget to use jupiter, vintage engines + platform
> > stack,
> > > otherwise code is compatible with 1.2 which gets loaded. The doc
> ignores
> > > the platform and vintage engine and guess it was not tested at all
> > checking
> > > the code ;). Not a big deal since it is a "first" release but we should
> > be
> > > ablz to get it fixed quickly.
> > >
> > >
> > > Le mar. 4 sept. 2018 23:51, Olivier Lamy  a écrit :
> > >
> > > > Ok perso I don't mind (it just need to be documented)
> > > > But the issue is: users are used to simply upgrade their junit
> > > dependency.
> > > >
> > > >
> > > > On Wed, 5 Sep 2018 at 07:37, Christian Stein 
> > wrote:
> > > >
> > > > > No, it works with Surefire 2.22.0 and JUnit 5.3.
> > > > >
> > > > > Just add (or move) the test-runtime dependencies to the Surefire
> > plugin
> > > > > element:
> > > > >
> > > > > 
> > > > >
> > > > >   
> > > > >   
> > > > >  maven-surefire-plugin
> > > > >  2.22.0
> > > > >  
> > > > >
> > > > >org.junit.jupiter
> > > > >
> junit-jupiter-engine
> > > > >5.3.0
> > > > >
> > > > >  
> > > > >   
> > > > >
> > > > > 
> > > > >
> > > > >
> > > > > Just checking our sample builds over at JUnit 5. Which do _NOT_ do
> > this
> > > > at
> > > > > the moment.
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Sep 4, 2018 at 11:32 PM Olivier Lamy 
> > wrote:
> > > > >
> > > > > > Hi
> > > > > > very embarrassing issue which probably worth a quick release!
> > > > > > Can you create a jira?
> > > > > > As junit 5.3.0 has just been released,  I might be happy to cut
> > > 2.22.1
> > > > > very
> > > > > > quickly with only this fix.
> > > > > > others wdyt?
> > > > > >
> > > > > >
> > > > > > On Wed, 5 Sep 2018 at 06:46, Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi guys,
> > > > > > >
> > > > > > > Jira seems down so sending a mail.
> > > > > > >
> > > > > > > I wanted to upgrade Meecrowave to JUnit 5.3 since it is out
> but I
> > > > > > realized
> > > > > > > the way surefire provider was developped for JUnit 5 was
> forcing
> > > the
> > > > > > > junit-platform-engine even adding it manually in the test
> > > > dependencies
> > > > > or
> > > > > > > plugin dependencies.
> > > > > > >
> > > > > > > Side note: I didn't investigated other providers but I guess it
> > is
> > > > the
> > > > > > > exact same but the API breakage are happening less often.
> > > > > > >
> > > > > > > I therefore created a PR to fix that ->
> > > > > > > https://github.com/apache/maven-surefire/pull/193
> > > > > > >
> > > > > > > Note: I didn't upgrade the JUnit 5 version in the same release
> > but
> > > it
> > > > > > > should probably be done too in another commit/PR.
> > > > > > >
> > > > > > > I wonder if you have release plans which could include this. In
> > > terms
> > > > > of
> > > > > > > issues I have in mind the other thing about JUnit 5 which would
> > be
> > > > > great
> > > > > > to

Re: issue with junit 5 integration

[Romain Manni-Bucau]

jupiter ;)

junit 5 is not jupiter but platform+ engine*s* so it must detect the full
stack and not just the default. A first step can be to detect
platform+jupiter+engine but I guess we will get spock, cucumber etc engine
quickly so being generic can be worth it. In my case I have vintage-engine
- cause i have junit4 and junit5 extensions and it is broken cause vintage
uses platform method of the 1.3.0 and the surefire provider forces 1.2.0.

In my proposal, the project dependencies (likely scope test on user side or
compile for engine/extension writers) is used and the plugin can
override/force some dependencies if needed. Alternative surefire could get
a specific config for that, not sure it does worth it.

Hope it is clearer.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 5 sept. 2018 à 07:41, Dan Tran  a écrit :

> Odd, I am under impression  surefire auto detect  junit-jupiter-engine  at
> runtime
>
> am I missing something?
>
> -D
>
> On Tue, Sep 4, 2018 at 10:08 PM Romain Manni-Bucau 
> wrote:
>
> > It does _NOT_ work and as mentionned you can test on meecrowave trying to
> > upgrade the version in junit module.
> >
> > The test classpath build ignores project and plugin dependencies. It
> faked
> > working until 5.3.0-RC1 cause no breakage was visible.
> >
> > When testing, dont forget to use jupiter, vintage engines + platform
> stack,
> > otherwise code is compatible with 1.2 which gets loaded. The doc ignores
> > the platform and vintage engine and guess it was not tested at all
> checking
> > the code ;). Not a big deal since it is a "first" release but we should
> be
> > ablz to get it fixed quickly.
> >
> >
> > Le mar. 4 sept. 2018 23:51, Olivier Lamy  a écrit :
> >
> > > Ok perso I don't mind (it just need to be documented)
> > > But the issue is: users are used to simply upgrade their junit
> > dependency.
> > >
> > >
> > > On Wed, 5 Sep 2018 at 07:37, Christian Stein 
> wrote:
> > >
> > > > No, it works with Surefire 2.22.0 and JUnit 5.3.
> > > >
> > > > Just add (or move) the test-runtime dependencies to the Surefire
> plugin
> > > > element:
> > > >
> > > > 
> > > >
> > > >   
> > > >   
> > > >  maven-surefire-plugin
> > > >  2.22.0
> > > >  
> > > >
> > > >org.junit.jupiter
> > > >junit-jupiter-engine
> > > >5.3.0
> > > >
> > > >  
> > > >   
> > > >
> > > > 
> > > >
> > > >
> > > > Just checking our sample builds over at JUnit 5. Which do _NOT_ do
> this
> > > at
> > > > the moment.
> > > >
> > > >
> > > >
> > > > On Tue, Sep 4, 2018 at 11:32 PM Olivier Lamy 
> wrote:
> > > >
> > > > > Hi
> > > > > very embarrassing issue which probably worth a quick release!
> > > > > Can you create a jira?
> > > > > As junit 5.3.0 has just been released,  I might be happy to cut
> > 2.22.1
> > > > very
> > > > > quickly with only this fix.
> > > > > others wdyt?
> > > > >
> > > > >
> > > > > On Wed, 5 Sep 2018 at 06:46, Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Hi guys,
> > > > > >
> > > > > > Jira seems down so sending a mail.
> > > > > >
> > > > > > I wanted to upgrade Meecrowave to JUnit 5.3 since it is out but I
> > > > > realized
> > > > > > the way surefire provider was developped for JUnit 5 was forcing
> > the
> > > > > > junit-platform-engine even adding it manually in the test
> > > dependencies
> > > > or
> > > > > > plugin dependencies.
> > > > > >
> > > > > > Side note: I didn't investigated other providers but I guess it
> is
> > > the
> > > > > > exact same but the API breakage are happening less often.
> > > > > >
> > > > > > I therefore created a PR to fix that ->
> > > > > > https://github.com/apache/maven-surefire/pull/193
> > > > > >
> > > > > > Note: I didn't upgrade the JUnit 5 version in the same release
> but
> > it
> > > > > > should probably be done too in another commit/PR.
> > > > > >
> > > > > > I wonder if you have release plans which could include this. In
> > terms
> > > > of
> > > > > > issues I have in mind the other thing about JUnit 5 which would
> be
> > > > great
> > > > > to
> > > > > > add is the support for display names instead of using the
> > class+test
> > > > > names
> > > > > > in the logs and reports but this is less mandatory than previous
> > one
> > > > > which
> > > > > > fails with a NoSuchMethod error when using vintage engine.
> > > > > >
> > > > > > Romain Manni-Bucau
> > > > > > @rmannibucau  |  Blog
> > > > > >  | Old Blog
> > > > > >