Re: maven-surefire-plugin add artifact as additionalClasspathElement
thanks,
I gave a second try to extensions and it seems works now.
stephane
Le 2023-02-23 à 09:52, Alexander Kriegisch a écrit :
Would you not rather write a Maven plugin or extension for something
like that and hook it into the build process globally, so you can use it
when specifying `repository` or `pluginReporitory` entries in the POM
needing it? This does not seem to be something limited to certain
plugins, if I understand correctly.
Alexander Kriegisch
https://scrum-master.de
Stephane Passignat schrieb am 22.02.2023 um 11:27:
Hello,
thank you everyone for these suggestions. Let's go back to my original
issue.
I need to add a library to maven classpath. The library I need is
another RepositoryLayoutFactory, to download artifact located is a
repository which is not yet supported by Maven. Actually it's a basic
HTTP server. (It could be an FTP server or a database accessed is JDBC...)
The library is made, it works (as well as I need), but to use it I need
to add it to maven/lib/ext which is not portable to other computer. So
I'm looking at alternatives. Surefire could be a candidate, or not...
I hope this helps to understand.
regards,
Stephane
Le 2023-02-16 à 11:58, Olivier Lamy a écrit :
On Thu, 16 Feb 2023 at 20:52, Olivier Lamy wrote:
On Thu, 16 Feb 2023 at 20:07, Delany wrote:
Hi Stephane,
You can do like this
maven-surefire-plugin
3.0.0-M9
org.apache.commons
commons-email
1.5
this will add dependencies to the surefire plugin itself.
I guess Stephane wants to add to the jvm running the tests?
additionalClasspathElement expect a full path to a directory or a file
to be added to the classpath
should work with something such but you need to assume commons-email
has been resolved locally as a dependency.
${settings.localRepository}/org/apache/commons/commons-email/1.5/commons-email-1.5.jar
another solution is to use dependency:copy to copy the commons-email
dependency somewhere in ./target and use this path (see
https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html)
a real example here :)
https://github.com/apache/maven-surefire/blob/master/surefire-providers/common-junit48/pom.xml
hth
Olivier
On Thu, 16 Feb 2023 at 11:25, Stephane Passignat
wrote:
Hello,
Is it possible to add a maven artifact as an additionalClasspathElement ?
I tried this syntax, inspired by the exclusion mechanism, but it's not
working.
org.apache.maven.plugins
maven-surefire-plugin
3.0.0-M9
org.apache.commons:commons-email:1.5
thank you
Stéphane
-
To unsubscribe,e-mail:users-unsubscr...@maven.apache.org
For additional commands,e-mail:users-h...@maven.apache.org
-
To unsubscribe, e-mail:users-unsubscr...@maven.apache.org
For additional commands, e-mail:users-h...@maven.apache.org
--
*Stéphane Passignat*
✆ +33 6 62 57 47 86
✉ passig...@hotmail.com
📍 3 place Jacques Marette, 75015 PARIS
Re: maven-surefire-plugin add artifact as additionalClasspathElement
Stephane,
"I need to add a library to maven classpath" -> you declare it as a
dependency, or I don't get quite the problem (looking at your last but also
first mail)
You can declare the artifact as project dependency (POM/dependencies) or as
plugin dependency (surefire/dependency), which one is the one you want?
To make maven able to use your new layout, did you try ,mvn/extensions.xml ?
https://maven.apache.org/guides/mini/guide-using-extensions.html
HTH
Tamas
On Wed, Feb 22, 2023 at 11:12 PM Stephane Passignat
wrote:
> Hello,
>
> thank you everyone for these suggestions. Let's go back to my original
> issue.
>
> I need to add a library to maven classpath. The library I need is
> another RepositoryLayoutFactory, to download artifact located is a
> repository which is not yet supported by Maven. Actually it's a basic
> HTTP server. (It could be an FTP server or a database accessed is JDBC...)
>
> The library is made, it works (as well as I need), but to use it I need
> to add it to maven/lib/ext which is not portable to other computer. So
> I'm looking at alternatives. Surefire could be a candidate, or not...
>
>
> I hope this helps to understand.
>
> regards,
>
>
> Stephane
>
>
> Le 2023-02-16 à 11:58, Olivier Lamy a écrit :
> > On Thu, 16 Feb 2023 at 20:52, Olivier Lamy wrote:
> >> On Thu, 16 Feb 2023 at 20:07, Delany
> wrote:
> >>> Hi Stephane,
> >>>
> >>> You can do like this
> >>>
> >>>
> >>>maven-surefire-plugin
> >>>3.0.0-M9
> >>>
> >>>
> >>>org.apache.commons
> >>>commons-email
> >>>1.5
> >>>
> >>>
> >>>
> >> this will add dependencies to the surefire plugin itself.
> >> I guess Stephane wants to add to the jvm running the tests?
> >>
> >> additionalClasspathElement expect a full path to a directory or a file
> >> to be added to the classpath
> >>
> >> should work with something such but you need to assume commons-email
> >> has been resolved locally as a dependency.
> >>
> ${settings.localRepository}/org/apache/commons/commons-email/1.5/commons-email-1.5.jar
> >>
> >> another solution is to use dependency:copy to copy the commons-email
> >> dependency somewhere in ./target and use this path (see
> >>
> https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html
> )
> >>
> > a real example here :)
> >
> https://github.com/apache/maven-surefire/blob/master/surefire-providers/common-junit48/pom.xml
> >
> >> hth
> >> Olivier
> >>
> >>> On Thu, 16 Feb 2023 at 11:25, Stephane Passignat >
> >>> wrote:
> >>>
> Hello,
>
> Is it possible to add a maven artifact as an
> additionalClasspathElement ?
>
> I tried this syntax, inspired by the exclusion mechanism, but it's not
> working.
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.0.0-M9
>
>
>
>
> org.apache.commons:commons-email:1.5
>
>
>
>
>
>
>
> thank you
>
> Stéphane
>
> > -
> > To unsubscribe, e-mail:users-unsubscr...@maven.apache.org
> > For additional commands, e-mail:users-h...@maven.apache.org
> >
> --
> *Stéphane Passignat*
> ✆ +33 6 62 57 47 86
> ✉ passig...@hotmail.com
> 📍 3 place Jacques Marette, 75015 PARIS
>
Re: maven-surefire-plugin add artifact as additionalClasspathElement
Would you not rather write a Maven plugin or extension for something
like that and hook it into the build process globally, so you can use it
when specifying `repository` or `pluginReporitory` entries in the POM
needing it? This does not seem to be something limited to certain
plugins, if I understand correctly.
Alexander Kriegisch
https://scrum-master.de
Stephane Passignat schrieb am 22.02.2023 um 11:27:
> Hello,
>
> thank you everyone for these suggestions. Let's go back to my original
> issue.
>
> I need to add a library to maven classpath. The library I need is
> another RepositoryLayoutFactory, to download artifact located is a
> repository which is not yet supported by Maven. Actually it's a basic
> HTTP server. (It could be an FTP server or a database accessed is JDBC...)
>
> The library is made, it works (as well as I need), but to use it I need
> to add it to maven/lib/ext which is not portable to other computer. So
> I'm looking at alternatives. Surefire could be a candidate, or not...
>
>
> I hope this helps to understand.
>
> regards,
>
>
> Stephane
>
>
> Le 2023-02-16 à 11:58, Olivier Lamy a écrit :
>> On Thu, 16 Feb 2023 at 20:52, Olivier Lamy wrote:
>>> On Thu, 16 Feb 2023 at 20:07, Delany wrote:
Hi Stephane,
You can do like this
maven-surefire-plugin
3.0.0-M9
org.apache.commons
commons-email
1.5
>>> this will add dependencies to the surefire plugin itself.
>>> I guess Stephane wants to add to the jvm running the tests?
>>>
>>> additionalClasspathElement expect a full path to a directory or a file
>>> to be added to the classpath
>>>
>>> should work with something such but you need to assume commons-email
>>> has been resolved locally as a dependency.
>>> ${settings.localRepository}/org/apache/commons/commons-email/1.5/commons-email-1.5.jar
>>>
>>> another solution is to use dependency:copy to copy the commons-email
>>> dependency somewhere in ./target and use this path (see
>>> https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html)
>>>
>> a real example here :)
>> https://github.com/apache/maven-surefire/blob/master/surefire-providers/common-junit48/pom.xml
>>
>>> hth
>>> Olivier
>>>
On Thu, 16 Feb 2023 at 11:25, Stephane Passignat
wrote:
> Hello,
>
> Is it possible to add a maven artifact as an additionalClasspathElement ?
>
> I tried this syntax, inspired by the exclusion mechanism, but it's not
> working.
>
>
>
>
>org.apache.maven.plugins
>maven-surefire-plugin
>3.0.0-M9
>
>
>
> org.apache.commons:commons-email:1.5
>
>
>
>
>
>
>
> thank you
>
> Stéphane
>
>> -
>> To unsubscribe, e-mail:users-unsubscr...@maven.apache.org
>> For additional commands, e-mail:users-h...@maven.apache.org
>>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin add artifact as additionalClasspathElement
Hello,
thank you everyone for these suggestions. Let's go back to my original
issue.
I need to add a library to maven classpath. The library I need is
another RepositoryLayoutFactory, to download artifact located is a
repository which is not yet supported by Maven. Actually it's a basic
HTTP server. (It could be an FTP server or a database accessed is JDBC...)
The library is made, it works (as well as I need), but to use it I need
to add it to maven/lib/ext which is not portable to other computer. So
I'm looking at alternatives. Surefire could be a candidate, or not...
I hope this helps to understand.
regards,
Stephane
Le 2023-02-16 à 11:58, Olivier Lamy a écrit :
On Thu, 16 Feb 2023 at 20:52, Olivier Lamy wrote:
On Thu, 16 Feb 2023 at 20:07, Delany wrote:
Hi Stephane,
You can do like this
maven-surefire-plugin
3.0.0-M9
org.apache.commons
commons-email
1.5
this will add dependencies to the surefire plugin itself.
I guess Stephane wants to add to the jvm running the tests?
additionalClasspathElement expect a full path to a directory or a file
to be added to the classpath
should work with something such but you need to assume commons-email
has been resolved locally as a dependency.
${settings.localRepository}/org/apache/commons/commons-email/1.5/commons-email-1.5.jar
another solution is to use dependency:copy to copy the commons-email
dependency somewhere in ./target and use this path (see
https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html)
a real example here :)
https://github.com/apache/maven-surefire/blob/master/surefire-providers/common-junit48/pom.xml
hth
Olivier
On Thu, 16 Feb 2023 at 11:25, Stephane Passignat
wrote:
Hello,
Is it possible to add a maven artifact as an additionalClasspathElement ?
I tried this syntax, inspired by the exclusion mechanism, but it's not
working.
org.apache.maven.plugins
maven-surefire-plugin
3.0.0-M9
org.apache.commons:commons-email:1.5
thank you
Stéphane
-
To unsubscribe, e-mail:users-unsubscr...@maven.apache.org
For additional commands, e-mail:users-h...@maven.apache.org
--
*Stéphane Passignat*
✆ +33 6 62 57 47 86
✉ passig...@hotmail.com
📍 3 place Jacques Marette, 75015 PARIS
Re: maven-surefire-plugin add artifact as additionalClasspathElement
Oh right, I thought he was going to fix something in surefire
There's also https://maven.apache.org/guides/mini/guide-attached-tests.html
-
- org.apache.maven.plugins
- maven-surefire-plugin
- ${surefire.version}
-
-
-
com.myco.app:foo-core:test-jar:tests
-
-
Delany
On Thu, 16 Feb 2023 at 12:53, Olivier Lamy wrote:
> On Thu, 16 Feb 2023 at 20:07, Delany wrote:
> >
> > Hi Stephane,
> >
> > You can do like this
> >
> >
> > maven-surefire-plugin
> > 3.0.0-M9
> >
> >
> > org.apache.commons
> > commons-email
> > 1.5
> >
> >
> >
>
> this will add dependencies to the surefire plugin itself.
> I guess Stephane wants to add to the jvm running the tests?
>
> additionalClasspathElement expect a full path to a directory or a file
> to be added to the classpath
>
> should work with something such but you need to assume commons-email
> has been resolved locally as a dependency.
>
> ${settings.localRepository}/org/apache/commons/commons-email/1.5/commons-email-1.5.jar
>
> another solution is to use dependency:copy to copy the commons-email
> dependency somewhere in ./target and use this path (see
>
> https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html
> )
>
> hth
> Olivier
>
> >
> > On Thu, 16 Feb 2023 at 11:25, Stephane Passignat
> > wrote:
> >
> > > Hello,
> > >
> > > Is it possible to add a maven artifact as an
> additionalClasspathElement ?
> > >
> > > I tried this syntax, inspired by the exclusion mechanism, but it's not
> > > working.
> > >
> > >
> > >
> > >
> > > org.apache.maven.plugins
> > > maven-surefire-plugin
> > > 3.0.0-M9
> > >
> > >
> > >
> > >
> org.apache.commons:commons-email:1.5
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > thank you
> > >
> > > Stéphane
> > >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
Re: maven-surefire-plugin add artifact as additionalClasspathElement
I agree that the current syntax for adding to stuff to test runtime is
clunky and I wouldn't personally use it unless I needed to.
On Thu, Feb 16, 2023 at 1:07 PM Alexander Kriegisch
wrote:
>
> Which is exactly why I was asking. I want to learn about real-world use
> cases which would require such a thing, not be just nice to have.
> Over-engineering POMs does not make them more readable or maintainable.
>
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Mikael Åsberg schrieb am 16.02.2023 um 13:03:
> > I use runtime scope a lot, but personally can't recall having needed
> > the equivalent of a test-runtime scope myself (or, more likely, I
> > could get away with test compile scope even though the dependency was
> > only needed at test runtime). But just because I haven't needed it
> > doesn't mean there are no legit circumstances.
> >
> > On Thu, Feb 16, 2023 at 12:57 PM Alexander Kriegisch
> > wrote:
> >>
> >> For a test, does it really matter to make the dependency test-scoped?
> >>
> >> Mikael Åsberg schrieb am 16.02.2023 um 12:35:
> >>> Because there exists runtime, but no test only runtime
> >>> scope
> >>>
> >>> On Thu, Feb 16, 2023 at 12:22 PM Alexander Kriegisch
> >>> wrote:
>
> I would be more interested first in why this should be necessary at all.
> What is the use case that would not be covered by declaring a regular
> test-scoped dependency in the module?
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Olivier Lamy schrieb am 16.02.2023 um 11:58:
> > On Thu, 16 Feb 2023 at 20:52, Olivier Lamy wrote:
> >>
> >> On Thu, 16 Feb 2023 at 20:07, Delany
> >> wrote:
> >>>
> >>> Hi Stephane,
> >>>
> >>> You can do like this
> >>>
> >>>
> >>> maven-surefire-plugin
> >>> 3.0.0-M9
> >>>
> >>>
> >>> org.apache.commons
> >>> commons-email
> >>> 1.5
> >>>
> >>>
> >>>
> >>
> >> this will add dependencies to the surefire plugin itself.
> >> I guess Stephane wants to add to the jvm running the tests?
> >>
> >> additionalClasspathElement expect a full path to a directory or a file
> >> to be added to the classpath
> >>
> >> should work with something such but you need to assume commons-email
> >> has been resolved locally as a dependency.
> >> ${settings.localRepository}/org/apache/commons/commons-email/1.5/commons-email-1.5.jar
> >>
> >> another solution is to use dependency:copy to copy the commons-email
> >> dependency somewhere in ./target and use this path (see
> >> https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html)
> >>
> >
> > a real example here :)
> > https://github.com/apache/maven-surefire/blob/master/surefire-providers/common-junit48/pom.xml
> >
> >> hth
> >> Olivier
> >>
> >>>
> >>> On Thu, 16 Feb 2023 at 11:25, Stephane Passignat
> >>>
> >>> wrote:
> >>>
> Hello,
>
> Is it possible to add a maven artifact as an
> additionalClasspathElement ?
>
> I tried this syntax, inspired by the exclusion mechanism, but it's
> not
> working.
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.0.0-M9
>
>
>
> org.apache.commons:commons-email:1.5
>
>
>
>
>
>
>
> thank you
>
> Stéphane
>
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: users-h...@maven.apache.org
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
>
Re: maven-surefire-plugin add artifact as additionalClasspathElement
Which is exactly why I was asking. I want to learn about real-world use
cases which would require such a thing, not be just nice to have.
Over-engineering POMs does not make them more readable or maintainable.
Alexander Kriegisch
https://scrum-master.de
Mikael Åsberg schrieb am 16.02.2023 um 13:03:
> I use runtime scope a lot, but personally can't recall having needed
> the equivalent of a test-runtime scope myself (or, more likely, I
> could get away with test compile scope even though the dependency was
> only needed at test runtime). But just because I haven't needed it
> doesn't mean there are no legit circumstances.
>
> On Thu, Feb 16, 2023 at 12:57 PM Alexander Kriegisch
> wrote:
>>
>> For a test, does it really matter to make the dependency test-scoped?
>>
>> Mikael Åsberg schrieb am 16.02.2023 um 12:35:
>>> Because there exists runtime, but no test only runtime scope
>>>
>>> On Thu, Feb 16, 2023 at 12:22 PM Alexander Kriegisch
>>> wrote:
I would be more interested first in why this should be necessary at all.
What is the use case that would not be covered by declaring a regular
test-scoped dependency in the module?
--
Alexander Kriegisch
https://scrum-master.de
Olivier Lamy schrieb am 16.02.2023 um 11:58:
> On Thu, 16 Feb 2023 at 20:52, Olivier Lamy wrote:
>>
>> On Thu, 16 Feb 2023 at 20:07, Delany wrote:
>>>
>>> Hi Stephane,
>>>
>>> You can do like this
>>>
>>>
>>> maven-surefire-plugin
>>> 3.0.0-M9
>>>
>>>
>>> org.apache.commons
>>> commons-email
>>> 1.5
>>>
>>>
>>>
>>
>> this will add dependencies to the surefire plugin itself.
>> I guess Stephane wants to add to the jvm running the tests?
>>
>> additionalClasspathElement expect a full path to a directory or a file
>> to be added to the classpath
>>
>> should work with something such but you need to assume commons-email
>> has been resolved locally as a dependency.
>> ${settings.localRepository}/org/apache/commons/commons-email/1.5/commons-email-1.5.jar
>>
>> another solution is to use dependency:copy to copy the commons-email
>> dependency somewhere in ./target and use this path (see
>> https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html)
>>
>
> a real example here :)
> https://github.com/apache/maven-surefire/blob/master/surefire-providers/common-junit48/pom.xml
>
>> hth
>> Olivier
>>
>>>
>>> On Thu, 16 Feb 2023 at 11:25, Stephane Passignat
>>> wrote:
>>>
Hello,
Is it possible to add a maven artifact as an
additionalClasspathElement ?
I tried this syntax, inspired by the exclusion mechanism, but it's not
working.
org.apache.maven.plugins
maven-surefire-plugin
3.0.0-M9
org.apache.commons:commons-email:1.5
thank you
Stéphane
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin add artifact as additionalClasspathElement
I use runtime scope a lot, but personally can't recall having needed
the equivalent of a test-runtime scope myself (or, more likely, I
could get away with test compile scope even though the dependency was
only needed at test runtime). But just because I haven't needed it
doesn't mean there are no legit circumstances.
On Thu, Feb 16, 2023 at 12:57 PM Alexander Kriegisch
wrote:
>
> For a test, does it really matter to make the dependency test-scoped?
>
> Mikael Åsberg schrieb am 16.02.2023 um 12:35:
> > Because there exists runtime, but no test only runtime scope
> >
> > On Thu, Feb 16, 2023 at 12:22 PM Alexander Kriegisch
> > wrote:
> >>
> >> I would be more interested first in why this should be necessary at all.
> >> What is the use case that would not be covered by declaring a regular
> >> test-scoped dependency in the module?
> >> --
> >> Alexander Kriegisch
> >> https://scrum-master.de
> >>
> >>
> >> Olivier Lamy schrieb am 16.02.2023 um 11:58:
> >>> On Thu, 16 Feb 2023 at 20:52, Olivier Lamy wrote:
>
> On Thu, 16 Feb 2023 at 20:07, Delany wrote:
> >
> > Hi Stephane,
> >
> > You can do like this
> >
> >
> > maven-surefire-plugin
> > 3.0.0-M9
> >
> >
> > org.apache.commons
> > commons-email
> > 1.5
> >
> >
> >
>
> this will add dependencies to the surefire plugin itself.
> I guess Stephane wants to add to the jvm running the tests?
>
> additionalClasspathElement expect a full path to a directory or a file
> to be added to the classpath
>
> should work with something such but you need to assume commons-email
> has been resolved locally as a dependency.
> ${settings.localRepository}/org/apache/commons/commons-email/1.5/commons-email-1.5.jar
>
> another solution is to use dependency:copy to copy the commons-email
> dependency somewhere in ./target and use this path (see
> https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html)
>
> >>>
> >>> a real example here :)
> >>> https://github.com/apache/maven-surefire/blob/master/surefire-providers/common-junit48/pom.xml
> >>>
> hth
> Olivier
>
> >
> > On Thu, 16 Feb 2023 at 11:25, Stephane Passignat
> > wrote:
> >
> >> Hello,
> >>
> >> Is it possible to add a maven artifact as an
> >> additionalClasspathElement ?
> >>
> >> I tried this syntax, inspired by the exclusion mechanism, but it's not
> >> working.
> >>
> >>
> >>
> >>
> >> org.apache.maven.plugins
> >> maven-surefire-plugin
> >> 3.0.0-M9
> >>
> >>
> >>
> >> org.apache.commons:commons-email:1.5
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> thank you
> >>
> >> Stéphane
> >>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: users-h...@maven.apache.org
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin add artifact as additionalClasspathElement
For a test, does it really matter to make the dependency test-scoped?
Mikael Åsberg schrieb am 16.02.2023 um 12:35:
> Because there exists runtime, but no test only runtime scope
>
> On Thu, Feb 16, 2023 at 12:22 PM Alexander Kriegisch
> wrote:
>>
>> I would be more interested first in why this should be necessary at all.
>> What is the use case that would not be covered by declaring a regular
>> test-scoped dependency in the module?
>> --
>> Alexander Kriegisch
>> https://scrum-master.de
>>
>>
>> Olivier Lamy schrieb am 16.02.2023 um 11:58:
>>> On Thu, 16 Feb 2023 at 20:52, Olivier Lamy wrote:
On Thu, 16 Feb 2023 at 20:07, Delany wrote:
>
> Hi Stephane,
>
> You can do like this
>
>
> maven-surefire-plugin
> 3.0.0-M9
>
>
> org.apache.commons
> commons-email
> 1.5
>
>
>
this will add dependencies to the surefire plugin itself.
I guess Stephane wants to add to the jvm running the tests?
additionalClasspathElement expect a full path to a directory or a file
to be added to the classpath
should work with something such but you need to assume commons-email
has been resolved locally as a dependency.
${settings.localRepository}/org/apache/commons/commons-email/1.5/commons-email-1.5.jar
another solution is to use dependency:copy to copy the commons-email
dependency somewhere in ./target and use this path (see
https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html)
>>>
>>> a real example here :)
>>> https://github.com/apache/maven-surefire/blob/master/surefire-providers/common-junit48/pom.xml
>>>
hth
Olivier
>
> On Thu, 16 Feb 2023 at 11:25, Stephane Passignat
> wrote:
>
>> Hello,
>>
>> Is it possible to add a maven artifact as an additionalClasspathElement ?
>>
>> I tried this syntax, inspired by the exclusion mechanism, but it's not
>> working.
>>
>>
>>
>>
>> org.apache.maven.plugins
>> maven-surefire-plugin
>> 3.0.0-M9
>>
>>
>>
>> org.apache.commons:commons-email:1.5
>>
>>
>>
>>
>>
>>
>>
>> thank you
>>
>> Stéphane
>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin add artifact as additionalClasspathElement
Because there exists runtime, but no test only runtime scope
On Thu, Feb 16, 2023 at 12:22 PM Alexander Kriegisch
wrote:
>
> I would be more interested first in why this should be necessary at all.
> What is the use case that would not be covered by declaring a regular
> test-scoped dependency in the module?
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Olivier Lamy schrieb am 16.02.2023 um 11:58:
> > On Thu, 16 Feb 2023 at 20:52, Olivier Lamy wrote:
> >>
> >> On Thu, 16 Feb 2023 at 20:07, Delany wrote:
> >>>
> >>> Hi Stephane,
> >>>
> >>> You can do like this
> >>>
> >>>
> >>> maven-surefire-plugin
> >>> 3.0.0-M9
> >>>
> >>>
> >>> org.apache.commons
> >>> commons-email
> >>> 1.5
> >>>
> >>>
> >>>
> >>
> >> this will add dependencies to the surefire plugin itself.
> >> I guess Stephane wants to add to the jvm running the tests?
> >>
> >> additionalClasspathElement expect a full path to a directory or a file
> >> to be added to the classpath
> >>
> >> should work with something such but you need to assume commons-email
> >> has been resolved locally as a dependency.
> >> ${settings.localRepository}/org/apache/commons/commons-email/1.5/commons-email-1.5.jar
> >>
> >> another solution is to use dependency:copy to copy the commons-email
> >> dependency somewhere in ./target and use this path (see
> >> https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html)
> >>
> >
> > a real example here :)
> > https://github.com/apache/maven-surefire/blob/master/surefire-providers/common-junit48/pom.xml
> >
> >> hth
> >> Olivier
> >>
> >>>
> >>> On Thu, 16 Feb 2023 at 11:25, Stephane Passignat
> >>> wrote:
> >>>
> Hello,
>
> Is it possible to add a maven artifact as an additionalClasspathElement ?
>
> I tried this syntax, inspired by the exclusion mechanism, but it's not
> working.
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.0.0-M9
>
>
>
> org.apache.commons:commons-email:1.5
>
>
>
>
>
>
>
> thank you
>
> Stéphane
>
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin add artifact as additionalClasspathElement
I would be more interested first in why this should be necessary at all.
What is the use case that would not be covered by declaring a regular
test-scoped dependency in the module?
--
Alexander Kriegisch
https://scrum-master.de
Olivier Lamy schrieb am 16.02.2023 um 11:58:
> On Thu, 16 Feb 2023 at 20:52, Olivier Lamy wrote:
>>
>> On Thu, 16 Feb 2023 at 20:07, Delany wrote:
>>>
>>> Hi Stephane,
>>>
>>> You can do like this
>>>
>>>
>>> maven-surefire-plugin
>>> 3.0.0-M9
>>>
>>>
>>> org.apache.commons
>>> commons-email
>>> 1.5
>>>
>>>
>>>
>>
>> this will add dependencies to the surefire plugin itself.
>> I guess Stephane wants to add to the jvm running the tests?
>>
>> additionalClasspathElement expect a full path to a directory or a file
>> to be added to the classpath
>>
>> should work with something such but you need to assume commons-email
>> has been resolved locally as a dependency.
>> ${settings.localRepository}/org/apache/commons/commons-email/1.5/commons-email-1.5.jar
>>
>> another solution is to use dependency:copy to copy the commons-email
>> dependency somewhere in ./target and use this path (see
>> https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html)
>>
>
> a real example here :)
> https://github.com/apache/maven-surefire/blob/master/surefire-providers/common-junit48/pom.xml
>
>> hth
>> Olivier
>>
>>>
>>> On Thu, 16 Feb 2023 at 11:25, Stephane Passignat
>>> wrote:
>>>
Hello,
Is it possible to add a maven artifact as an additionalClasspathElement ?
I tried this syntax, inspired by the exclusion mechanism, but it's not
working.
org.apache.maven.plugins
maven-surefire-plugin
3.0.0-M9
org.apache.commons:commons-email:1.5
thank you
Stéphane
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin add artifact as additionalClasspathElement
On Thu, 16 Feb 2023 at 20:52, Olivier Lamy wrote:
>
> On Thu, 16 Feb 2023 at 20:07, Delany wrote:
> >
> > Hi Stephane,
> >
> > You can do like this
> >
> >
> > maven-surefire-plugin
> > 3.0.0-M9
> >
> >
> > org.apache.commons
> > commons-email
> > 1.5
> >
> >
> >
>
> this will add dependencies to the surefire plugin itself.
> I guess Stephane wants to add to the jvm running the tests?
>
> additionalClasspathElement expect a full path to a directory or a file
> to be added to the classpath
>
> should work with something such but you need to assume commons-email
> has been resolved locally as a dependency.
> ${settings.localRepository}/org/apache/commons/commons-email/1.5/commons-email-1.5.jar
>
> another solution is to use dependency:copy to copy the commons-email
> dependency somewhere in ./target and use this path (see
> https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html)
>
a real example here :)
https://github.com/apache/maven-surefire/blob/master/surefire-providers/common-junit48/pom.xml
> hth
> Olivier
>
> >
> > On Thu, 16 Feb 2023 at 11:25, Stephane Passignat
> > wrote:
> >
> > > Hello,
> > >
> > > Is it possible to add a maven artifact as an additionalClasspathElement ?
> > >
> > > I tried this syntax, inspired by the exclusion mechanism, but it's not
> > > working.
> > >
> > >
> > >
> > >
> > > org.apache.maven.plugins
> > > maven-surefire-plugin
> > > 3.0.0-M9
> > >
> > >
> > >
> > > org.apache.commons:commons-email:1.5
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > thank you
> > >
> > > Stéphane
> > >
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin add artifact as additionalClasspathElement
On Thu, 16 Feb 2023 at 20:07, Delany wrote:
>
> Hi Stephane,
>
> You can do like this
>
>
> maven-surefire-plugin
> 3.0.0-M9
>
>
> org.apache.commons
> commons-email
> 1.5
>
>
>
this will add dependencies to the surefire plugin itself.
I guess Stephane wants to add to the jvm running the tests?
additionalClasspathElement expect a full path to a directory or a file
to be added to the classpath
should work with something such but you need to assume commons-email
has been resolved locally as a dependency.
${settings.localRepository}/org/apache/commons/commons-email/1.5/commons-email-1.5.jar
another solution is to use dependency:copy to copy the commons-email
dependency somewhere in ./target and use this path (see
https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html)
hth
Olivier
>
> On Thu, 16 Feb 2023 at 11:25, Stephane Passignat
> wrote:
>
> > Hello,
> >
> > Is it possible to add a maven artifact as an additionalClasspathElement ?
> >
> > I tried this syntax, inspired by the exclusion mechanism, but it's not
> > working.
> >
> >
> >
> >
> > org.apache.maven.plugins
> > maven-surefire-plugin
> > 3.0.0-M9
> >
> >
> >
> > org.apache.commons:commons-email:1.5
> >
> >
> >
> >
> >
> >
> >
> > thank you
> >
> > Stéphane
> >
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin add artifact as additionalClasspathElement
Hi Stephane, You can do like this maven-surefire-plugin 3.0.0-M9 org.apache.commons commons-email 1.5 On Thu, 16 Feb 2023 at 11:25, Stephane Passignat wrote: > Hello, > > Is it possible to add a maven artifact as an additionalClasspathElement ? > > I tried this syntax, inspired by the exclusion mechanism, but it's not > working. > > > > > org.apache.maven.plugins > maven-surefire-plugin > 3.0.0-M9 > > > > org.apache.commons:commons-email:1.5 > > > > > > > > thank you > > Stéphane >
Re: maven-surefire-plugin jdkToolchain meets forkCount
Yes it looks that way. I changed the system jdk to 16 and now I can pick a jdk with the toolchains plugin and without any surefire config. Its basically https://issues.apache.org/jira/browse/MTOOLCHAINS-28 all over again but with surefire-plugin Want a ticket? Delany On Thu, 26 Aug 2021 at 17:50, Thomas Broyer wrote: > IIUC, with forkCount=0, you're disabling forking, so everything happens in > the Maven process itself and won't use the configured toolchain. If you're > running Maven with a JDK < 9 then you'd have that > UnsupportedClassVersionError. > > For the first case, with forkCount being its default value (forkCount=1) I > suppose, can you share the stacktrace? > It might be (I haven't checked) that the plugin looks at (loads) the > compiled classes to determine how to actually fork/run the tests (e.g. > determine if a given class is a test class, by looking at the @Test > annotations with JUnit 4 for instance). If that's the case then it means > you have to run Maven with a JDK version greater than the one you'd want to > use as a toolchain. In other words you can run Maven with JDK 11 to run > your tests with JDK 8, but not run Maven with JDK 8 to run tests with JDK > 11. > > On Thu, Aug 26, 2021 at 3:32 PM Delany wrote: > > > Hi. Im having trouble with the jdkToolchain feature of > > maven-surefire-plugin > > > > > https://maven.apache.org/surefire/maven-surefire-plugin/examples/toolchains.html > > This is my working build tag > > > > > > > > > > > > maven-compiler-plugin > > > > 8 > > 8 > > > > > > > > maven-surefire-plugin > > > > > > 9 > > > > > > > > > > > > > > > > maven-toolchains-plugin > > > > > > > > > > > > 9 > > > > > > > > > > > > > > > > > > > > I can build with the above config no problem, but if I configure the > > compile plugin with 9, surefire throws > > > > > Execution default-test of goal > > org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed: > > java.lang.UnsupportedClassVersionError: > > com/etc/common/crypto/clientreference/TestClientToken has been compiled > by > > a more recent version of the Java Runtime (class file version 53.0), this > > version of the Java Runtime only recognizes class file versions up to > 52.0 > > > > In either case I can see the toolchain being configured in the build log > > > > [INFO] --- maven-compiler-plugin:3.8.1:testCompile (default-testCompile) > @ > > cryptocommon --- > > [INFO] Toolchain in maven-compiler-plugin: JDK[/usr/lib/jvm/zulu-9-amd64] > > [INFO] Changes detected - recompiling the module! > > [INFO] Compiling 7 source files to > > /git/tep22x/common_cryptocommon/target/test-classes > > [INFO] > > [INFO] --- maven-surefire-plugin:3.0.0-M5:test (default-test) @ > > cryptocommon --- > > [INFO] Toolchain in maven-surefire-plugin: JDK[/usr/lib/jvm/zulu-9-amd64] > > > > Now, if on top of my changes thus far I go and configure surefire-plugin > > with 1, it's back to a successful build. > > > > But, if I follow the advice of > > > > > https://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html > > and rather set 0, I get this > > > > [ERROR] Exception in provider > > [ERROR] org.apache.maven.surefire.booter.SurefireExecutionException: > > Exception in provider > > [ERROR] at > > > > > org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.runSuitesInProcess(InPluginVMSurefireStarter.java:91) > > [ERROR] at > > > > > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1295) > > [ERROR] at > > > > > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1159) > > [ERROR] at > > > > > org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:932) > > [ERROR] at > > > > > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137) > > [ERROR] at > > > > > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210) > > [ERROR] at > > > > > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156) > > [ERROR] at > > > > > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) > > [ERROR] at > > > > > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117) > > [ERROR] at > > > > > org.apache.maven.lifecycle.internal.builder.multit
Re: maven-surefire-plugin jdkToolchain meets forkCount
IIUC, with forkCount=0, you're disabling forking, so everything happens in the Maven process itself and won't use the configured toolchain. If you're running Maven with a JDK < 9 then you'd have that UnsupportedClassVersionError. For the first case, with forkCount being its default value (forkCount=1) I suppose, can you share the stacktrace? It might be (I haven't checked) that the plugin looks at (loads) the compiled classes to determine how to actually fork/run the tests (e.g. determine if a given class is a test class, by looking at the @Test annotations with JUnit 4 for instance). If that's the case then it means you have to run Maven with a JDK version greater than the one you'd want to use as a toolchain. In other words you can run Maven with JDK 11 to run your tests with JDK 8, but not run Maven with JDK 8 to run tests with JDK 11. On Thu, Aug 26, 2021 at 3:32 PM Delany wrote: > Hi. Im having trouble with the jdkToolchain feature of > maven-surefire-plugin > > https://maven.apache.org/surefire/maven-surefire-plugin/examples/toolchains.html > This is my working build tag > > > > > > maven-compiler-plugin > > 8 > 8 > > > > maven-surefire-plugin > > > 9 > > > > > > > > maven-toolchains-plugin > > > > > > 9 > > > > > > > > > > I can build with the above config no problem, but if I configure the > compile plugin with 9, surefire throws > > > Execution default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed: > java.lang.UnsupportedClassVersionError: > com/etc/common/crypto/clientreference/TestClientToken has been compiled by > a more recent version of the Java Runtime (class file version 53.0), this > version of the Java Runtime only recognizes class file versions up to 52.0 > > In either case I can see the toolchain being configured in the build log > > [INFO] --- maven-compiler-plugin:3.8.1:testCompile (default-testCompile) @ > cryptocommon --- > [INFO] Toolchain in maven-compiler-plugin: JDK[/usr/lib/jvm/zulu-9-amd64] > [INFO] Changes detected - recompiling the module! > [INFO] Compiling 7 source files to > /git/tep22x/common_cryptocommon/target/test-classes > [INFO] > [INFO] --- maven-surefire-plugin:3.0.0-M5:test (default-test) @ > cryptocommon --- > [INFO] Toolchain in maven-surefire-plugin: JDK[/usr/lib/jvm/zulu-9-amd64] > > Now, if on top of my changes thus far I go and configure surefire-plugin > with 1, it's back to a successful build. > > But, if I follow the advice of > > https://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html > and rather set 0, I get this > > [ERROR] Exception in provider > [ERROR] org.apache.maven.surefire.booter.SurefireExecutionException: > Exception in provider > [ERROR] at > > org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.runSuitesInProcess(InPluginVMSurefireStarter.java:91) > [ERROR] at > > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1295) > [ERROR] at > > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1159) > [ERROR] at > > org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:932) > [ERROR] at > > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137) > [ERROR] at > > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210) > [ERROR] at > > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156) > [ERROR] at > > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) > [ERROR] at > > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117) > [ERROR] at > > org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:196) > [ERROR] at > > org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:186) > [ERROR] at java.util.concurrent.FutureTask.run(FutureTask.java:266) > [ERROR] at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > [ERROR] at java.util.concurrent.FutureTask.run(FutureTask.java:266) > [ERROR] at > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > [ERROR] at > > java.util.co
Re: maven-surefire-plugin jdkToolchain meets forkCount
>From the looks of it, your toolchains plugin might not get executed. Are you sure you've configured execution phase to "validate" in toolchains plugin? Last when I had to use toolchains plugin I don't remember needing to configure particular surefire properties. See java9 with toolchains.xml https://maven.apache.org/surefire/maven-surefire-plugin/java9.html org.apache.maven.plugins maven-toolchains-plugin 1.1 validate toolchain 9 On Thu, Aug 26, 2021 at 1:31 PM Delany wrote: > > Hi. Im having trouble with the jdkToolchain feature of maven-surefire-plugin > https://maven.apache.org/surefire/maven-surefire-plugin/examples/toolchains.html > This is my working build tag > > > > > > maven-compiler-plugin > > 8 > 8 > > > > maven-surefire-plugin > > > 9 > > > > > > > > maven-toolchains-plugin > > > > > > 9 > > > > > > > > > > I can build with the above config no problem, but if I configure the > compile plugin with 9, surefire throws > > > Execution default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed: > java.lang.UnsupportedClassVersionError: > com/etc/common/crypto/clientreference/TestClientToken has been compiled by > a more recent version of the Java Runtime (class file version 53.0), this > version of the Java Runtime only recognizes class file versions up to 52.0 > > In either case I can see the toolchain being configured in the build log > > [INFO] --- maven-compiler-plugin:3.8.1:testCompile (default-testCompile) @ > cryptocommon --- > [INFO] Toolchain in maven-compiler-plugin: JDK[/usr/lib/jvm/zulu-9-amd64] > [INFO] Changes detected - recompiling the module! > [INFO] Compiling 7 source files to > /git/tep22x/common_cryptocommon/target/test-classes > [INFO] > [INFO] --- maven-surefire-plugin:3.0.0-M5:test (default-test) @ > cryptocommon --- > [INFO] Toolchain in maven-surefire-plugin: JDK[/usr/lib/jvm/zulu-9-amd64] > > Now, if on top of my changes thus far I go and configure surefire-plugin > with 1, it's back to a successful build. > > But, if I follow the advice of > https://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html > and rather set 0, I get this > > [ERROR] Exception in provider > [ERROR] org.apache.maven.surefire.booter.SurefireExecutionException: > Exception in provider > [ERROR] at > org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.runSuitesInProcess(InPluginVMSurefireStarter.java:91) > [ERROR] at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1295) > [ERROR] at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1159) > [ERROR] at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:932) > [ERROR] at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137) > [ERROR] at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210) > [ERROR] at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156) > [ERROR] at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) > [ERROR] at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117) > [ERROR] at > org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:196) > [ERROR] at > org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:186) > [ERROR] at java.util.concurrent.FutureTask.run(FutureTask.java:266) > [ERROR] at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > [ERROR] at java.util.concurrent.FutureTask.run(FutureTask.java:266) > [ERROR] at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > [ERROR] at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > [ERROR] at java.lang.Thread.run(Thread.java:748) > [ERROR] Caused by: java.lang.UnsupportedClassVersionError: > com/traderoot/common/crypto/clientreference/TestClientToken has been > compiled by a more recent version of the Java Runtime (class
Re: Maven surefire plugin: parallel configuration not running tests in parallel
We will do our best as well. On one hand TeamCity uses flowId based on
Thread ID, the surefire plugin can use a similar mechanism we used before
in surefire-junit47-provider and we can identify the lines of system output
by Thread ID.
T
On Wed, Feb 17, 2021 at 6:31 PM Jay Crosley wrote:
> My plan is to run these serially for local development and in parallel for
> TeamCity, and for TeamCity I think it will pick out the logs using flowId,
> so hopefully that will work.
>
> From: Tibor Digana
> Date: Wednesday, February 17, 2021 at 2:19 AM
> To: Maven Users List
> Subject: Re: Maven surefire plugin: parallel configuration not running
> tests in parallel
> In case of combining JUnit5 and Surefire/Failsafe, the configuration
> parameters e.g. "parallel" and "threadCountClasses" are not bound to the
> native JUnit parameters "junit.jupiter.execution.parallel.enabled" because
> it was an agreement between Maven/JUnit teams and the solution became "by
> design". We can talk about a new concept and bind these parameters of
> course.
>
> Regarding the parallel execution has it's own logging problems in plugin on
> the top of JUnit5 engine but that's another issue you may be facing. We are
> approaching the fix step by step.
>
> Cheers
> Tibor
>
> On Tue, Feb 16, 2021 at 11:04 PM Jay Crosley wrote:
>
> > I’m trying to get junit5 tests to run in parallel using the maven
> surefire
> > plugin, as described on
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__maven.apache.org_surefire_maven-2Dsurefire-2Dplugin_examples_fork-2Doptions-2Dand-2Dparallel-2Dexecution.html&d=DwIFaQ&c=0hefKdg9jtsMu47wpF0ovg&r=qyxGgg8iek4zUTwPHqQd2x5bP20ZI2bxMqb2S9cASmw&m=M_2Gjt2FtuqAHQQ0HhrtLwLB6txc8A381wmGzx0q2jw&s=9y-T5guZoywkTqejMKcpEcM60c0Eg_HNafGvBD39cxM&e=
> .
> > Despite configuration that looks correct, I can’t get them to run in
> > parallel. I’ll paste my configuration and what I’ve tried and experienced
> > so far. Any help is greatly appreciated!
> >
> > My surefire plugin configuration looks like this:
> >
> >
> >
> > org.apache.maven.plugins
> > maven-surefire-plugin
> > 2.21.0
> >
> >
> > org.junit.platform
> > junit-platform-surefire-provider
> > 1.2.0
> >
> >
> > org.junit.jupiter
> > junit-jupiter-engine
> > 5.2.0
> >
> >
> >
> >
> > And I have a maven profile setup with additional configuration for our
> > integration tests, which includes the parallel configuration. The
> commented
> > out configurations indicate all the things I’ve tried.
> >
> >
> >
> > integration-tests-local
> >
> >
> >
> > org.apache.maven.plugins
> > maven-surefire-plugin
> > ${surefire.version}
> >
> > classes
> > 4
> > true
> >
> >
> >
> >
> >
> > false
> >
> > false
> >
> > none
> >
> >
> > **/*IntegrationTests*.java
> >
> >
> >
> >
> >
> >
> > The project is structured with a parent pom.xml and several sub-projects.
> > The tests are in the “integration-tests” module, which pulls in the
> > surefire plugin with no additional configuration:
> >
> >
> >
> > maven-surefire-plugin
> >
> >
> > I mention the sub-project because it means that the maven command I’m
> > running looks like this (I’ve tried with/without the “-T”):
> >
> >
> > mvn -T 4 test -e -pl integration-tests -am -Pintegration-tests-local
> >
> > For the purposes of debugging, I’ve created 10 .java files named
> > TestIntegrationTests1.java through TestIntegrationTests10.java, each of
> > which has 10 unit tests all of which look like this:
> >
> >
> > package com.axon.scorpius.integration_tests;
> >
> > import static org.junit.jupiter.api.Assertions.assertTrue;
> >
> > import org.junit.jupiter.api.Test;
> >
> > /**
> > * Tests.
> > */
> > public class TestIntegrationTests1 {
> >
> > @Test
> > void test1() {
> > try {
> > Thread.sleep(1000);
> > } catch (InterruptedException ex) {
> > System.out.println("Interrupted exception: " + ex);
> >
Re: Maven surefire plugin: parallel configuration not running tests in parallel
My plan is to run these serially for local development and in parallel for
TeamCity, and for TeamCity I think it will pick out the logs using flowId, so
hopefully that will work.
From: Tibor Digana
Date: Wednesday, February 17, 2021 at 2:19 AM
To: Maven Users List
Subject: Re: Maven surefire plugin: parallel configuration not running tests in
parallel
In case of combining JUnit5 and Surefire/Failsafe, the configuration
parameters e.g. "parallel" and "threadCountClasses" are not bound to the
native JUnit parameters "junit.jupiter.execution.parallel.enabled" because
it was an agreement between Maven/JUnit teams and the solution became "by
design". We can talk about a new concept and bind these parameters of
course.
Regarding the parallel execution has it's own logging problems in plugin on
the top of JUnit5 engine but that's another issue you may be facing. We are
approaching the fix step by step.
Cheers
Tibor
On Tue, Feb 16, 2021 at 11:04 PM Jay Crosley wrote:
> I’m trying to get junit5 tests to run in parallel using the maven surefire
> plugin, as described on
> https://urldefense.proofpoint.com/v2/url?u=https-3A__maven.apache.org_surefire_maven-2Dsurefire-2Dplugin_examples_fork-2Doptions-2Dand-2Dparallel-2Dexecution.html&d=DwIFaQ&c=0hefKdg9jtsMu47wpF0ovg&r=qyxGgg8iek4zUTwPHqQd2x5bP20ZI2bxMqb2S9cASmw&m=M_2Gjt2FtuqAHQQ0HhrtLwLB6txc8A381wmGzx0q2jw&s=9y-T5guZoywkTqejMKcpEcM60c0Eg_HNafGvBD39cxM&e=
> .
> Despite configuration that looks correct, I can’t get them to run in
> parallel. I’ll paste my configuration and what I’ve tried and experienced
> so far. Any help is greatly appreciated!
>
> My surefire plugin configuration looks like this:
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.21.0
>
>
> org.junit.platform
> junit-platform-surefire-provider
> 1.2.0
>
>
> org.junit.jupiter
> junit-jupiter-engine
> 5.2.0
>
>
>
>
> And I have a maven profile setup with additional configuration for our
> integration tests, which includes the parallel configuration. The commented
> out configurations indicate all the things I’ve tried.
>
>
>
> integration-tests-local
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> ${surefire.version}
>
> classes
> 4
> true
>
>
>
>
>
> false
>
> false
>
> none
>
>
> **/*IntegrationTests*.java
>
>
>
>
>
>
> The project is structured with a parent pom.xml and several sub-projects.
> The tests are in the “integration-tests” module, which pulls in the
> surefire plugin with no additional configuration:
>
>
>
> maven-surefire-plugin
>
>
> I mention the sub-project because it means that the maven command I’m
> running looks like this (I’ve tried with/without the “-T”):
>
>
> mvn -T 4 test -e -pl integration-tests -am -Pintegration-tests-local
>
> For the purposes of debugging, I’ve created 10 .java files named
> TestIntegrationTests1.java through TestIntegrationTests10.java, each of
> which has 10 unit tests all of which look like this:
>
>
> package com.axon.scorpius.integration_tests;
>
> import static org.junit.jupiter.api.Assertions.assertTrue;
>
> import org.junit.jupiter.api.Test;
>
> /**
> * Tests.
> */
> public class TestIntegrationTests1 {
>
> @Test
> void test1() {
> try {
> Thread.sleep(1000);
> } catch (InterruptedException ex) {
> System.out.println("Interrupted exception: " + ex);
> }
>
> assertTrue(true);
> }
>
>
>
> … 9 identical tests
>
> My hope is that when I run “mvn test” (I’m running locally in iTerm on a
> Macbook), these 10 test classes will run in parallel (at least partially),
> but they run serially, as seen here:
>
> INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests4
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.057 s - in com.axon.scorpius.integration_tests.TestIntegrationTests4
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests6
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.029 s - in com.axon.scorpius.integration_tests.TestIntegrationTests6
> [IN
Re: Maven surefire plugin: parallel configuration not running tests in parallel
In case of combining JUnit5 and Surefire/Failsafe, the configuration
parameters e.g. "parallel" and "threadCountClasses" are not bound to the
native JUnit parameters "junit.jupiter.execution.parallel.enabled" because
it was an agreement between Maven/JUnit teams and the solution became "by
design". We can talk about a new concept and bind these parameters of
course.
Regarding the parallel execution has it's own logging problems in plugin on
the top of JUnit5 engine but that's another issue you may be facing. We are
approaching the fix step by step.
Cheers
Tibor
On Tue, Feb 16, 2021 at 11:04 PM Jay Crosley wrote:
> I’m trying to get junit5 tests to run in parallel using the maven surefire
> plugin, as described on
> https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html.
> Despite configuration that looks correct, I can’t get them to run in
> parallel. I’ll paste my configuration and what I’ve tried and experienced
> so far. Any help is greatly appreciated!
>
> My surefire plugin configuration looks like this:
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.21.0
>
>
> org.junit.platform
> junit-platform-surefire-provider
> 1.2.0
>
>
> org.junit.jupiter
> junit-jupiter-engine
> 5.2.0
>
>
>
>
> And I have a maven profile setup with additional configuration for our
> integration tests, which includes the parallel configuration. The commented
> out configurations indicate all the things I’ve tried.
>
>
>
> integration-tests-local
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> ${surefire.version}
>
> classes
> 4
> true
>
>
>
>
>
> false
>
> false
>
> none
>
>
> **/*IntegrationTests*.java
>
>
>
>
>
>
> The project is structured with a parent pom.xml and several sub-projects.
> The tests are in the “integration-tests” module, which pulls in the
> surefire plugin with no additional configuration:
>
>
>
> maven-surefire-plugin
>
>
> I mention the sub-project because it means that the maven command I’m
> running looks like this (I’ve tried with/without the “-T”):
>
>
> mvn -T 4 test -e -pl integration-tests -am -Pintegration-tests-local
>
> For the purposes of debugging, I’ve created 10 .java files named
> TestIntegrationTests1.java through TestIntegrationTests10.java, each of
> which has 10 unit tests all of which look like this:
>
>
> package com.axon.scorpius.integration_tests;
>
> import static org.junit.jupiter.api.Assertions.assertTrue;
>
> import org.junit.jupiter.api.Test;
>
> /**
> * Tests.
> */
> public class TestIntegrationTests1 {
>
> @Test
> void test1() {
> try {
> Thread.sleep(1000);
> } catch (InterruptedException ex) {
> System.out.println("Interrupted exception: " + ex);
> }
>
> assertTrue(true);
> }
>
>
>
> … 9 identical tests
>
> My hope is that when I run “mvn test” (I’m running locally in iTerm on a
> Macbook), these 10 test classes will run in parallel (at least partially),
> but they run serially, as seen here:
>
> INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests4
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.057 s - in com.axon.scorpius.integration_tests.TestIntegrationTests4
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests6
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.029 s - in com.axon.scorpius.integration_tests.TestIntegrationTests6
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests10
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.025 s - in com.axon.scorpius.integration_tests.TestIntegrationTests10
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests2
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.027 s - in com.axon.scorpius.integration_tests.TestIntegrationTests2
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests7
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.032 s - in com.axon.scorpius.integration_tests.TestIntegrationTests7
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests5
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.027 s - in com.axon.scorpius.integration_tests.TestIntegrationTests5
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests1
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.032 s - in com.axon.scorpius
Re: Maven surefire plugin: parallel configuration not running tests in parallel
On Tue, Feb 16, 2021 at 4:18 PM Jay Crosley wrote: > I take it back, the maven-failsafe-plugin works with the junit > configuration options you suggested. That was the one combination I hadn’t > tried. Woo hoo! > I should have mentioned: there are no other configuration settings necessary. Best, Laird
Re: Maven surefire plugin: parallel configuration not running tests in parallel
I take it back, the maven-failsafe-plugin works with the junit configuration options you suggested. That was the one combination I hadn’t tried. Woo hoo! From: Laird Nelson Date: Tuesday, February 16, 2021 at 4:01 PM To: Maven Users List Subject: Re: Maven surefire plugin: parallel configuration not running tests in parallel On Tue, Feb 16, 2021 at 4:00 PM Jay Crosley wrote: > Thank you. That looked promising but alas, I get the same result. I tried > those with and without the other surefire configurations for running > parallel tests. I also tried (from browsing the web) the > maven-failsafe-plugin with the various configurations and get the same > result with that too. > Best of luck; that configuration works for sure. Best, Laird
Re: Maven surefire plugin: parallel configuration not running tests in parallel
On Tue, Feb 16, 2021 at 4:00 PM Jay Crosley wrote: > Thank you. That looked promising but alas, I get the same result. I tried > those with and without the other surefire configurations for running > parallel tests. I also tried (from browsing the web) the > maven-failsafe-plugin with the various configurations and get the same > result with that too. > Best of luck; that configuration works for sure. Best, Laird
Re: Maven surefire plugin: parallel configuration not running tests in parallel
Thank you. That looked promising but alas, I get the same result. I tried those
with and without the other surefire configurations for running parallel tests.
I also tried (from browsing the web) the maven-failsafe-plugin with the various
configurations and get the same result with that too.
From: Laird Nelson
Date: Tuesday, February 16, 2021 at 2:56 PM
To: Maven Users List
Subject: Re: Maven surefire plugin: parallel configuration not running tests in
parallel
JUnit5 does this in a strange way and they don't make it obvious.
Try a recipe like this:
maven-surefire-plugin
junit.jupiter.execution.parallel.enabled=true
junit.jupiter.execution.parallel.mode.default=concurrent
Best,
Laird
On Tue, Feb 16, 2021 at 2:04 PM Jay Crosley wrote:
> I’m trying to get junit5 tests to run in parallel using the maven surefire
> plugin, as described on
> https://urldefense.proofpoint.com/v2/url?u=https-3A__maven.apache.org_surefire_maven-2Dsurefire-2Dplugin_examples_fork-2Doptions-2Dand-2Dparallel-2Dexecution.html&d=DwIFaQ&c=0hefKdg9jtsMu47wpF0ovg&r=qyxGgg8iek4zUTwPHqQd2x5bP20ZI2bxMqb2S9cASmw&m=l4pkyWdpKGZmIkAgh8BX_Pucc2XXQLIcXqoMUG2MLQc&s=BDHGeYlib1BtRqkGRGkKw-wJorLBhcO0-Dh6mODYUhY&e=
> .
> Despite configuration that looks correct, I can’t get them to run in
> parallel. I’ll paste my configuration and what I’ve tried and experienced
> so far. Any help is greatly appreciated!
>
> My surefire plugin configuration looks like this:
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.21.0
>
>
> org.junit.platform
> junit-platform-surefire-provider
> 1.2.0
>
>
> org.junit.jupiter
> junit-jupiter-engine
> 5.2.0
>
>
>
>
> And I have a maven profile setup with additional configuration for our
> integration tests, which includes the parallel configuration. The commented
> out configurations indicate all the things I’ve tried.
>
>
>
> integration-tests-local
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> ${surefire.version}
>
> classes
> 4
> true
>
>
>
>
>
> false
>
> false
>
> none
>
>
> **/*IntegrationTests*.java
>
>
>
>
>
>
> The project is structured with a parent pom.xml and several sub-projects.
> The tests are in the “integration-tests” module, which pulls in the
> surefire plugin with no additional configuration:
>
>
>
> maven-surefire-plugin
>
>
> I mention the sub-project because it means that the maven command I’m
> running looks like this (I’ve tried with/without the “-T”):
>
>
> mvn -T 4 test -e -pl integration-tests -am -Pintegration-tests-local
>
> For the purposes of debugging, I’ve created 10 .java files named
> TestIntegrationTests1.java through TestIntegrationTests10.java, each of
> which has 10 unit tests all of which look like this:
>
>
> package com.axon.scorpius.integration_tests;
>
> import static org.junit.jupiter.api.Assertions.assertTrue;
>
> import org.junit.jupiter.api.Test;
>
> /**
> * Tests.
> */
> public class TestIntegrationTests1 {
>
> @Test
> void test1() {
> try {
> Thread.sleep(1000);
> } catch (InterruptedException ex) {
> System.out.println("Interrupted exception: " + ex);
> }
>
> assertTrue(true);
> }
>
>
>
> … 9 identical tests
>
> My hope is that when I run “mvn test” (I’m running locally in iTerm on a
> Macbook), these 10 test classes will run in parallel (at least partially),
> but they run serially, as seen here:
>
> INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests4
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.057 s - in com.axon.scorpius.integration_tests.TestIntegrationTests4
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests6
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.029 s - in com.axon.scorpius.integration_tests.TestIntegrationTests6
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests10
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.025 s - in com.axon.scorpius.integrat
Re: Maven surefire plugin: parallel configuration not running tests in parallel
JUnit5 does this in a strange way and they don't make it obvious.
Try a recipe like this:
maven-surefire-plugin
junit.jupiter.execution.parallel.enabled=true
junit.jupiter.execution.parallel.mode.default=concurrent
Best,
Laird
On Tue, Feb 16, 2021 at 2:04 PM Jay Crosley wrote:
> I’m trying to get junit5 tests to run in parallel using the maven surefire
> plugin, as described on
> https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html.
> Despite configuration that looks correct, I can’t get them to run in
> parallel. I’ll paste my configuration and what I’ve tried and experienced
> so far. Any help is greatly appreciated!
>
> My surefire plugin configuration looks like this:
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.21.0
>
>
> org.junit.platform
> junit-platform-surefire-provider
> 1.2.0
>
>
> org.junit.jupiter
> junit-jupiter-engine
> 5.2.0
>
>
>
>
> And I have a maven profile setup with additional configuration for our
> integration tests, which includes the parallel configuration. The commented
> out configurations indicate all the things I’ve tried.
>
>
>
> integration-tests-local
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> ${surefire.version}
>
> classes
> 4
> true
>
>
>
>
>
> false
>
> false
>
> none
>
>
> **/*IntegrationTests*.java
>
>
>
>
>
>
> The project is structured with a parent pom.xml and several sub-projects.
> The tests are in the “integration-tests” module, which pulls in the
> surefire plugin with no additional configuration:
>
>
>
> maven-surefire-plugin
>
>
> I mention the sub-project because it means that the maven command I’m
> running looks like this (I’ve tried with/without the “-T”):
>
>
> mvn -T 4 test -e -pl integration-tests -am -Pintegration-tests-local
>
> For the purposes of debugging, I’ve created 10 .java files named
> TestIntegrationTests1.java through TestIntegrationTests10.java, each of
> which has 10 unit tests all of which look like this:
>
>
> package com.axon.scorpius.integration_tests;
>
> import static org.junit.jupiter.api.Assertions.assertTrue;
>
> import org.junit.jupiter.api.Test;
>
> /**
> * Tests.
> */
> public class TestIntegrationTests1 {
>
> @Test
> void test1() {
> try {
> Thread.sleep(1000);
> } catch (InterruptedException ex) {
> System.out.println("Interrupted exception: " + ex);
> }
>
> assertTrue(true);
> }
>
>
>
> … 9 identical tests
>
> My hope is that when I run “mvn test” (I’m running locally in iTerm on a
> Macbook), these 10 test classes will run in parallel (at least partially),
> but they run serially, as seen here:
>
> INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests4
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.057 s - in com.axon.scorpius.integration_tests.TestIntegrationTests4
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests6
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.029 s - in com.axon.scorpius.integration_tests.TestIntegrationTests6
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests10
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.025 s - in com.axon.scorpius.integration_tests.TestIntegrationTests10
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests2
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.027 s - in com.axon.scorpius.integration_tests.TestIntegrationTests2
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests7
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.032 s - in com.axon.scorpius.integration_tests.TestIntegrationTests7
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests5
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.027 s - in com.axon.scorpius.integration_tests.TestIntegrationTests5
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests1
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.032 s - in com.axon.scorpius.integration_tests.TestIntegrationTests1
> [INFO] Running com.axon.scorpius.integration_tests.TestIntegrationTests3
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.036 s - in com.axon.scorpius.integration_tests.TestIntegrationTests3
> [INFO] Run
Re: maven-surefire-plugin does not fail build if TestNG and JUnit47 are used
I did try 2.17 to see if it would fix the problem but got an additional error (I forget what it was) so I reverted it back to 2.10. I ended up just converting the TestNG tests to use JUnit and all works fine now. -Dave On Fri, Sep 12, 2014 at 12:38 AM, Andreas Gudian wrote: > Hi, > > 2.10 is rather old. Could you try it with a more recent version such as > 2.17? > > > Am Donnerstag, 11. September 2014 schrieb David Hoffer : > > > I have a module where maven-surefire-plugin (2.10) is configured to use > > TestNG and JUnit47. The former has several tests that all succeed and > the > > later has two tests that fail. However the build succeeds. How can I > > configure surefire so the build fails if either have failures which is > the > > expected behavior? > > >
Re: maven-surefire-plugin does not fail build if TestNG and JUnit47 are used
Hi, 2.10 is rather old. Could you try it with a more recent version such as 2.17? Am Donnerstag, 11. September 2014 schrieb David Hoffer : > I have a module where maven-surefire-plugin (2.10) is configured to use > TestNG and JUnit47. The former has several tests that all succeed and the > later has two tests that fail. However the build succeeds. How can I > configure surefire so the build fails if either have failures which is the > expected behavior? >
Re: maven-surefire-plugin
Hi, The timeout is for each forked JVM process. So I you use reuseForks=true it counts for all the tests executed in each of the parallel forks (forkCount>=1). With reuseForks=false, it counts for each test class. Cheers, Andreas Am Mittwoch, 15. Mai 2013 schrieb : > > > Hello everyone > > I'm wondering about forkedProcessTimeoutInSeconds in the test mojo of the > maven-surefire-plugin. What is not clear from the docs is, is this timeout > reset per test? is it affected by the number of forks? > e.g. > if i have only 1 fork and i have 300 tests @ 1s each and I set the timeout > at 20s, will it fail the tests because the combined time is > 20s or as > long as one single test doesn't go over 20s they will all pass? > > Thank you > > > Alejandro Endo | Software Designer/Concepteur de logiciels > DISCLAIMER: > > Privileged and/or Confidential information may be contained in this > message. If you are not the addressee of this message, you may not > copy, use or deliver this message to anyone. In such event, you > should destroy the message and kindly notify the sender by reply > e-mail. It is understood that opinions or conclusions that do not > relate to the official business of the company are neither given > nor endorsed by the company. > > Thank You. > >
Re: maven-surefire-plugin 2.13: test order (know about runOrder)?
> Can one control the ordering of test *methods* inside a test class? I'm > using JUnit 4.11 and Surefire 2.13. > > It seems to me from the wording of the runOrder parameter this would be > used to choose what test *classes* to run in what order. > > One of our developers is pointing out that Surefire 2.13 seems to have > changed the order that it uses to run methods inside her test class. > > While I know and you don't have to tell me that ordering shouldn't be a > property of unit tests, I want to at least understand if it is > controllable > or not. If your test methods depend on the order in which they are executed they should be refactored to be atomic rather than trying to order them via the test framework. manfred - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin 2.13: test order (know about runOrder)?
On Tue, Feb 12, 2013 at 2:43 PM, Andreas Gudian wrote: > The execution order of the methods within a test class is in control of > Junit itself. > Thanks, Andreas; that explains it. Best, Laird -- http://about.me/lairdnelson
Re: maven-surefire-plugin 2.13: test order (know about runOrder)?
Hi Laird, The execution order of the methods within a test class is in control of Junit itself. AFAIK, Junit 4.11 contains a change to order the execution of @Test methods alphabetically by default. [1] has some information on how to control that behavior. I think what's now called the "JVM" sorting was the default behavior in previous versions. [1] http://www.hascode.com/2012/11/new-features-in-junit-4-11/#Test_Execution_Order Cheers, Andreas Am Dienstag, 12. Februar 2013 schrieb Laird Nelson : > Can one control the ordering of test *methods* inside a test class? I'm > using JUnit 4.11 and Surefire 2.13. > > It seems to me from the wording of the runOrder parameter this would be > used to choose what test *classes* to run in what order. > > One of our developers is pointing out that Surefire 2.13 seems to have > changed the order that it uses to run methods inside her test class. > > While I know and you don't have to tell me that ordering shouldn't be a > property of unit tests, I want to at least understand if it is controllable > or not. > > Thanks very much, > Best, > Laird > > -- > http://about.me/lairdnelson >
Re: [maven-surefire-plugin] Issue with -Dtest param under Windows
Cheers Dan!! just works as expected with 2.11. Just wondering why I'm so quick to upgrade to newer versions sometimes... -- View this message in context: http://maven.40175.n5.nabble.com/maven-surefire-plugin-Issue-with-Dtest-param-under-Windows-tp5518723p5521282.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [maven-surefire-plugin] Issue with -Dtest param under Windows
Just found out , we also hit similar issue with -Dtest param on windows. Revert back to surefire 2.11 fixes it the issue -D On Mon, Feb 27, 2012 at 8:10 AM, Wayne Fay wrote: >> I'm having an issue with 'mvn test -Dtest=' >> >> It works fine under Linux and OsX but under Windows the test is simply not >> found. > > Can you create a sample project that demonstrates this failure in the > functionality? If not, the likelihood of someone actually looking into > this is quite low. > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [maven-surefire-plugin] Issue with -Dtest param under Windows
> I'm having an issue with 'mvn test -Dtest=' > > It works fine under Linux and OsX but under Windows the test is simply not > found. Can you create a sample project that demonstrates this failure in the functionality? If not, the likelihood of someone actually looking into this is quite low. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin redirecting System.err and showing delayed output from junit tests
@Kristian, thank you for your kind help. More below... I have finally solved my immediate problem. The problem was introduced when I made a change to a spring configuration file that caused an exception during the spring context creation by spring due to the *@org.springframework.test.context.ContextConfiguration* in my JUnit test which extended *org.springframework.test.context.junit4.AbstractJUnit4SpringContextTests* class. When this happened all my tests failed but no interim output was produced as normally expected. Thus the entire suite took a very long time to run (with all tests failing on context creation) to run while not giving any feedback on individual test status. After all tests failed the entire buffered output was spit out in one big burst it seems. When I fixed my spring context file issue everything started working normally and I strarted seeing interim passed, FAILED messages on the console. maven-surefire-plugin version did not seem to make any different with 2.8, 2.9, 2.10. I did not try 2.8.1. As you can gather the scenario is rather complex and I do not have time to make a reproducable test case. Should I still file an issue? I am not sure whether the problem is a surefire-plugin issue of a spring-test issue. Thanks for your advice and help. -- View this message in context: http://maven.40175.n5.nabble.com/maven-surefire-plugin-redirecting-System-err-and-showing-delayed-output-from-junit-tests-tp4873335p4962045.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin redirecting System.err and showing delayed output from junit tests
System.err will always be redirected in the forked VM, there is no setting to avoid that. But the output should be piped through to the surefire-plugin and output from there instead, which should be identical (but quite obviously isn't totally the same ATM.) If you want this fixed you should probably do what I suggested in my original response, file a bug report with a small sample project to demonstrate your problem. Kristian to., 03.11.2011 kl. 08.36 -0700, skrev farrukh_najmi: > This issue has become a productivity loss nightmare for me. Debugger shows > that System.err is set to: > > org.apache.maven.surefirereport.ConsoleOutputCapture$ForwardingPrintStream > > Using useFile plugin config param with value false has no effect and > System.err is still redirected. > > What magic do I need to make sure that System.err does not get redirected? > > Please help me out of this hole. Thanks. > > > Kristian Rosenvold-4 wrote: > > > > There were some changes in the capture/buffering algorithm for test > > output for surefire 2.9, which might be what you are seeing. If you are > > running your tests in parallel, > > this is the intended behaviour, but I assume there might have been some > > change in the serial run-mode too, which is probably unintentional. This > > is not the > > kind of stuff our (extensive) test-cases would spot, since the end > > behaviour is correct. > > > > I think you should file an issue for this at > > http://jira.codehaus.org/browse/SUREFIRE, preferably attaching a small > > sample project that demonstrates the problem. > > > > You can use this project as a template for creating an example project > > https://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-integration-tests/src/test/resources/junit47-redirect-output* > > > > > > Kristian > > > > * > > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/maven-surefire-plugin-redirecting-System-err-and-showing-delayed-output-from-junit-tests-tp4873335p4961403.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin redirecting System.err and showing delayed output from junit tests
You would have to try version 2.8.1; I will take a look at this for 2.11. Kristian to., 03.11.2011 kl. 08.38 -0700, skrev farrukh_najmi: > Note that I have tried this with both maven-surefire-plugin 2.9 and 2.10 and > there is no difference. > > -- > View this message in context: > http://maven.40175.n5.nabble.com/maven-surefire-plugin-redirecting-System-err-and-showing-delayed-output-from-junit-tests-tp4873335p4961409.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin redirecting System.err and showing delayed output from junit tests
Note that I have tried this with both maven-surefire-plugin 2.9 and 2.10 and there is no difference. -- View this message in context: http://maven.40175.n5.nabble.com/maven-surefire-plugin-redirecting-System-err-and-showing-delayed-output-from-junit-tests-tp4873335p4961409.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin redirecting System.err and showing delayed output from junit tests
This issue has become a productivity loss nightmare for me. Debugger shows that System.err is set to: org.apache.maven.surefirereport.ConsoleOutputCapture$ForwardingPrintStream Using useFile plugin config param with value false has no effect and System.err is still redirected. What magic do I need to make sure that System.err does not get redirected? Please help me out of this hole. Thanks. Kristian Rosenvold-4 wrote: > > There were some changes in the capture/buffering algorithm for test > output for surefire 2.9, which might be what you are seeing. If you are > running your tests in parallel, > this is the intended behaviour, but I assume there might have been some > change in the serial run-mode too, which is probably unintentional. This > is not the > kind of stuff our (extensive) test-cases would spot, since the end > behaviour is correct. > > I think you should file an issue for this at > http://jira.codehaus.org/browse/SUREFIRE, preferably attaching a small > sample project that demonstrates the problem. > > You can use this project as a template for creating an example project > https://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-integration-tests/src/test/resources/junit47-redirect-output* > > > Kristian > > * > -- View this message in context: http://maven.40175.n5.nabble.com/maven-surefire-plugin-redirecting-System-err-and-showing-delayed-output-from-junit-tests-tp4873335p4961403.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin redirecting System.err and showing delayed output from junit tests
Den 05.10.2011 18:26, skrev Farrukh Najmi: Sometime in the recent past I noticed that when I run my projects junit tests via maven-surefire-plugin I no longer see the log messages or println statements sent to System.err until *after* the test completes. Since these message are important while debugging a test I need to see them as the test executes. I noticed in the debugger that System.err is redirected to some surefire specific class. Can any one tell me how I to get back the old behavior where all log messages and output to System.err is displayed on the console as it happens in real time? Thank you for your help. There were some changes in the capture/buffering algorithm for test output for surefire 2.9, which might be what you are seeing. If you are running your tests in parallel, this is the intended behaviour, but I assume there might have been some change in the serial run-mode too, which is probably unintentional. This is not the kind of stuff our (extensive) test-cases would spot, since the end behaviour is correct. I think you should file an issue for this at http://jira.codehaus.org/browse/SUREFIRE, preferably attaching a small sample project that demonstrates the problem. You can use this project as a template for creating an example project https://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-integration-tests/src/test/resources/junit47-redirect-output* Kristian *
Re: maven-surefire-plugin redirecting System.err and showing delayed output from junit tests
> Can any one tell me how I to get back the old behavior where all log > messages and output to System.err is displayed on the console as it happens > in real time? Did you check the documentation for the surefire plugin? http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html Try the useFile parameter. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin : when does it abort?
http://jira.codehaus.org/browse/SUREFIRE-580 On 8 July 2011 10:05, Marc SCHNEIDER wrote: > Hi, > > I have a test class with several test methods. > I suspect Surefire run all the tests even if there is a failure in one > method. > Am I right? > If this is the case, is there a way to tell Surefire to abort as soon as it > gets a failure? > > I'm using JUnit4 > > Thanks in advance, > Marc. > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven surefire plugin run twice with different argLine setttings
Thanks for your information. At the moment we cannot switch to Maven 3 yet. I understand the part to take up multiple executions within the same surefire plugin. But how will this work combined with the itblast-plugin. Normally the itblast-plugin sets the goal (execute) and to be able to run the itblast-plugin it uses the surefire plugin. Then itblast is instructed to run the tests against for instance a jetty6x container. And to use the itblast-plugin a surefire plugin is needed. But I don't know if adding more executions to the surefire plugin will work for me. Because actually the itblast-plugin should have two executions if I understand his correctly. -- View this message in context: http://maven.40175.n5.nabble.com/Maven-surefire-plugin-run-twice-with-different-argLine-setttings-tp4288014p4288333.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven surefire plugin run twice with different argLine setttings
On 7 April 2011 12:08, Stephen Connolly wrote:
> still bad...
>
> i'm going to guess that you defined the plugin twice, e.g.
>
>
> maven-surefire-plugin
> ...
>
>
> maven-surefire-plugin
> ...
>
Forgot to mention... I can conclude you are using Maven 2.x... Maven
3.x will tell you to take a long walk off a short pier if you attempt
to duplicate the same plugin in the pom.
Maven 2.x will just merge the two which is why the last one wins for you
>
> instead of adding an extra execution to the plugin
>
>
> maven-surefire-plugin
>
>
> ora
>
> ...
>
>
>
> mssql
>
> ...
>
>
>
>
>
> Now you should note that the above will run the tests three times!
> (there is a default execution of the plugin)
>
> In Maven 3.x you can disable the default execution with
>
>
> default-test
>
> true
>
>
>
> That won't work for Maven 2.x so if you need to support building with
> Maven 2.x then you either define one execution's configuration in the
> plugin configuration and reset the configuration back in the second
> configuration (i.e. you only have one execution defined in your pom)
>
> maven-surefire-plugin
>
>
> ...
>
>
>
> mssql
>
> ...
>
>
>
>
>
> or you do something like
>
>
> maven-surefire-plugin
>
> true
>
>
>
> ora
>
> ${skipTests}
> ...
>
>
>
> mssql
>
> ${skipTests}
> ...
>
>
>
>
>
> which will disable surefire by default and re-enable it based on the
> skipTests property for the two executions.
>
> On 7 April 2011 10:55, Hugo de Oude wrote:
>> Oh I'm sorry. I tried to correct the problem and hopefully it is ok now?
>>
>> --
>> View this message in context:
>> http://maven.40175.n5.nabble.com/Maven-surefire-plugin-run-twice-with-different-argLine-setttings-tp4288014p4288110.html
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven surefire plugin run twice with different argLine setttings
still bad...
i'm going to guess that you defined the plugin twice, e.g.
maven-surefire-plugin
...
maven-surefire-plugin
...
instead of adding an extra execution to the plugin
maven-surefire-plugin
ora
...
mssql
...
Now you should note that the above will run the tests three times!
(there is a default execution of the plugin)
In Maven 3.x you can disable the default execution with
default-test
true
That won't work for Maven 2.x so if you need to support building with
Maven 2.x then you either define one execution's configuration in the
plugin configuration and reset the configuration back in the second
configuration (i.e. you only have one execution defined in your pom)
maven-surefire-plugin
...
mssql
...
or you do something like
maven-surefire-plugin
true
ora
${skipTests}
...
mssql
${skipTests}
...
which will disable surefire by default and re-enable it based on the
skipTests property for the two executions.
On 7 April 2011 10:55, Hugo de Oude wrote:
> Oh I'm sorry. I tried to correct the problem and hopefully it is ok now?
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Maven-surefire-plugin-run-twice-with-different-argLine-setttings-tp4288014p4288110.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven surefire plugin run twice with different argLine setttings
Oh I'm sorry. I tried to correct the problem and hopefully it is ok now? -- View this message in context: http://maven.40175.n5.nabble.com/Maven-surefire-plugin-run-twice-with-different-argLine-setttings-tp4288014p4288110.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven surefire plugin run twice with different argLine setttings
Hi Hugo,
Your XML from both of your mails is garbled, unreadable (by Nabble UI if I'm
right).
Please use proper MUA or even better paste (http://pastebin.com/) or gist (
https://gist.github.com/) them and send the links to them instead.
Thanks,
~t~
On Thu, Apr 7, 2011 at 11:03 AM, Hugo de Oude wrote:
> Within our build process we would like to run all unittests twice. Because
> we
> would like to test everything against SQL Server and Oracle.
>
> To achieve this I added the maven-surefire-plugin to the pom twice. The
> first one has id 'run_tests_oracle_id' and the second one is called
> 'run_tests_sqlserver_id'.
> Now in the configuration I use the argLine to set which database has to be
> used.
> But each time when the build is executed the latest configuration of
> maven-surefire-plugin is used. So it seems not possible to load two
> maven-surefire-plugins with two different configurations?
>
> Does somebody know a solution for this? Main purpose is running all
> unittest
> twice on two different databases using maven-surefire-plugin and the
> itblast-plugin.
>
> Thx in advance.
>
>
>run_tests_oracle_id
>
>
>run_tests_oracle
>
>
>
>
>
>org.apache.maven.plugins
>maven-surefire-plugin
>2.8
>
> false
>
> ${VMARGS__TEST_PROPERTY_FILE_ORACLE}
> ${VMARGS__MAVEN_SUREFIRE_PLUGIN_1}
>false
>
>
> c:/_composer/_config/libraries/picketlink-bindings-1.0.4.final.jar
>
>
>
>
>
>org.twdata.maven
>maven-itblast-plugin
>0.5
>
>
>itblast_oracle
>
> post-integration-test
>
>
> execute
>
>
>
> tomcat5x
>
> ${APPSERVER_DB_ORACLE__PORT__HTTP}
>
> ${APPSERVER_DB_ORACLE__PORT__RMI}
>
> ${junit.test.pattern}
>
>
>
>
>
>
>
>
>
>
>
>run_tests_sqlserver_id
>
>
>run_tests_sqlserver
>
>
>
>
>
>
>org.apache.maven.plugins
>maven-surefire-plugin
>2.8
>
>false
>
> ${VMARGS__TEST_PROPERTY_FILE_SQLSERVER}
> ${VMARGS__MAVEN_SUREFIRE_PLUGIN_2}
>false
>
>
>
>
>org.twdata.maven
>maven-itblast-plugin
>0.5
>
>
>itblast_sqlserver
>verify
>
>
> execute
>
>
>
> jetty6x
>
> ${APPSERVER_DB_SQLSRV__PORT__HTTP}
>
> ${APPSERVER_DB_SQLSRV__PORT__RMI}
>
> ${junit.test.pattern}
>
>
>
>
>
>
>
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Maven-surefire-plugin-run-twice-with-different-argLine-setttings-tp4288014p4288014.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
Re: maven-surefire-plugin/maven3: junit4 and powermock/easymock support
Works fine on my machine using java 1.6 and maven 3.0.1. I had to remove
the sonar plugin though, because I don't have your database.
Kristian
on., 08.12.2010 kl. 14.05 +0100, skrev Raphael Bossek:
> Hi, you can find my simple project as ZIP and Maven3 project at the
> following zip download url: http://bit.ly/hpVtYc
> The mvn.log and org.raboss.javaexercise.ClassDefinitionTest.txt files
> (part of the zip archive) document the problem.
> To reproduce start "mvn test"
>
> Using PowerMock 1.4.6 and maven-surefire-plugin 2.5
>
> ---
> Test set: org.raboss.javaexercise.ClassDefinitionTest
> ---
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.149
> sec <<< FAILURE!
> org.raboss.javaexercise.ClassDefinitionTest.testStaticMainMethods()
> Time elapsed: 0.07 sec <<< FAILURE!
> java.lang.IllegalArgumentException: Cannot subclass final class class
> org.slf4j.LoggerFactory
>at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java:446)
>at
> net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:
> 25)
>at
> net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:
> 216)
>at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
>at net.sf.cglib.proxy.Enhancer.createClass(Enhancer.java:317)
>at
> org.easymock.internal.ClassProxyFactory.createProxy(ClassProxyFactory.java:
> 181)
>at org.easymock.internal.MocksControl.createMock(MocksControl.java:
> 60)
>at org.powermock.api.easymock.PowerMock.doCreateMock(PowerMock.java:
> 2211)
>at org.powermock.api.easymock.PowerMock.doMock(PowerMock.java:2162)
>at org.powermock.api.easymock.PowerMock.mockStatic(PowerMock.java:
> 296)
>at
> org.raboss.javaexercise.ClassDefinitionTest.testStaticMainMethods(ClassDefinitionTest.java:
> 45)
>
> Here the test class src/test/java/org/raboss/javaexercise/
> ClassDefinitionTest.java (from this zip archive):
>
> package org.raboss.javaexercise;
>
> import static org.powermock.api.easymock.PowerMock.createMock;
> import static org.powermock.api.easymock.PowerMock.replayAll;
> import static org.powermock.api.easymock.PowerMock.verifyAll;
> import static org.powermock.api.easymock.PowerMock.mockStatic;
> import static org.easymock.EasyMock.expect;
>
> import org.junit.Test;
> import org.junit.runner.RunWith;
> import org.powermock.core.classloader.annotations.*;
> import org.powermock.modules.junit4.PowerMockRunner;
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
>
> @RunWith(PowerMockRunner.class)
> @PrepareForTest({Logger.class, LoggerFactory.class,
> ClassDefinition.class})
> @SuppressStaticInitializationFor({"org.slf4j.LoggerFactory"})
> public class ClassDefinitionTest {
>@Test public void testNonDefaultConstructur() {
>final String msg = "testNonDefaultConstructur";
>Logger mock = createMock(Logger.class);
>mock.info(msg);
>replayAll();
>ClassDefinition probe = new ClassDefinition(mock);
>probe.process(msg);
>verifyAll();
>}
>
>@Test public void testStaticMainMethods() {
>final String[] msg = new String[] {"testStaticMainMethod"};
>Logger mockLogger = createMock(Logger.class);
>// Mock all static methods.
>mockStatic(LoggerFactory.class);
>
> expect(LoggerFactory.getLogger(ClassDefinition.class)).andReturn(mockLogger);
>mockLogger.info(msg[0]);
>replayAll();
>ClassDefinition.main(msg);
>verifyAll();
>}
> }
>
> The class under test (src/main/java/org/raboss/javaexercise/
> ClassDefinition.java) looks like:
>
> package org.raboss.javaexercise;
>
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
>
> public class ClassDefinition {
>private Logger logger;
>ClassDefinition(Logger logger) {
>this.logger = logger;
>}
>ClassDefinition() {
>this(LoggerFactory.getLogger(ClassDefinition.class));
>}
>public static void main(final String[] args) {
>ClassDefinition cd = new ClassDefinition();
>if(0 == args.length) {
>args[0] = "main";
>}
>cd.process(args[0]);
>}
>public final void setLogger(Logger logger) {
>this.logger = logger;
>}
>public final void process(String msg) {
>logger.info(msg);
>}
> }
>
> The mvn.log file contains the following information that is related to
> this issue:
> ---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
> [DEBUG] Configuring mojo
> org.apache.maven.p
RE: maven-surefire-plugin: Error creating properties files for forking
For the information of others that may encounter this behaviour in the near future, upgrading the JDK to version 1.5.0_22 appears to have resolved the issue. Kind regards Kevin From: Kevin Jervis Sent: Wednesday, February 03, 2010 13:21 To: users@maven.apache.org Subject: maven-surefire-plugin: Error creating properties files for forking Hi all, I am having difficulty getting the maven-surefire-plugin to execute some test cases. It seems to be having trouble generating the properties file after compiling the tests successfully, before forking to execute the tests. The preferred environment for executing the maven build is eclipse, but the same results can be observed on the command line. The surefire plugin is configured to always fork. It doesn't display the path it is trying to write the properties to, however I would assume this in my Windows XP profile temp directory (since I have seen old surefire properties files left around in this directory in the past) i.e. C:\Documents and Settings\kjervis\Local Settings\Temp. I have also tried overriding my profile defined TMP/TEMP environment variables to point to c:\Temp. Still the issue occurs. I am currently at a loss as how to proceed. The full log can be found attached, but for convenience please find the stacktrace below: Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error creating properties files for forking; nested exception is java.io.IOException: The system cannot find the path specified at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default LifecycleExecutor.java:583) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec ycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultL ifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec ycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error creating properties files for forking; nested exception is java.io.IOException: The system cannot find the path specified at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.j ava:541) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMa nager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default LifecycleExecutor.java:558) ... 16 more Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException: Error creating properties files for forking; nested exception is java.io.IOException: The system cannot find the path specified at org.apache.maven.surefire.booter.SurefireBooter.fork(SurefireBooter.java :629) at org.apache.maven.surefire.booter.SurefireBooter.forkSuite(SurefireBooter .java:493) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesForkPerTestSet( SurefireBooter.java:412) at org.apache.maven.surefire.booter.SurefireBooter.run(SurefireBooter.java: 249) at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.j ava:537) ... 18 more Caused by: java.io.IOException: The system cannot find the path specified at java.io.WinNTFileSystem.createFileExclusively(Native Method) at java.io.File.checkAndCreate(File.java:1345) at java.io.File.createTempFile(File.java:1434) at java.io.File.createTempFile(File.java:1471) at org.apache.maven.surefire.booter.SurefireBooter.writePropertiesFile(Sure fireBooter.java:523) at org.apache.maven.surefire.booter.SurefireBooter.fork(SurefireBooter.java :621) ... 22 more Kevin Versions: maven-surefire-plugin: 2.4.3 maven: 2.0.9/2.2.1 JDK: 1.5.0_16
Re: Maven Surefire Plugin don't run JUnit tests if TestNG in dependencies
I'd say that if it doesn't work for you and you have a project that re-produces this, file a bug report. /Anders On Wed, Oct 21, 2009 at 16:16, Bulat Nigmatullin wrote: > I need someone to prove my suspicions. Please check provided project. > > -- > > Bulat Nigmatullin. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Maven Surefire Plugin don't run JUnit tests if TestNG in dependencies
I need someone to prove my suspicions. Please check provided project. -- Bulat Nigmatullin. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Surefire Plugin don't run JUnit tests if TestNG in dependencies
If you have a project to reproduce, it would be great if you created a jira so that it could be fixed. http://jira.codehaus.org/browse/SUREFIRE /Anders On Wed, Oct 21, 2009 at 15:51, Bulat Nigmatullin wrote: > According to >> http://maven.apache.org/plugins/maven-surefire-plugin/usage.html >> it should work with both TestNG and JUnit. >> > > I read that, but it don't true. I attached example project, that prove my > words. > > I removed TestNG from dependencies. > > Bulat Nigmatullin > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org >
Re: Maven Surefire Plugin don't run JUnit tests if TestNG in dependencies
According to http://maven.apache.org/plugins/maven-surefire-plugin/usage.html it should work with both TestNG and JUnit. What I'm wondering about is why TestNG is getting into your classpath. Your dependency should typically have a test scope dependency to TestNG, which will be omitted in the transitive dependency. Something is strange here. Or do you have a dependency to an artifact including test classes which have compile scope dependency to TestNG? One way to solve this is to add a dependency exclusion for TestNG on your dependency. /Anders On Wed, Oct 21, 2009 at 14:54, Bulat Nigmatullin wrote: > I have a project with a lot of JUnit test. Recently I've added new > dependency wich have TestNG in it's dependencies. From that moment > Surefire plugins don't run JUnit test anymore. It seems to me that > Surefire tries to find TestNG tests but not find them and don't search > for JUnit tests. Is this behaviour correct and how can i fix this? > > I have the following line in log: > > --- > T E S T S > --- > Running TestSuite > Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.117 > sec > > Results : > > Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 > > > Best regards, > Bulat Nigmatullin > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: maven-surefire-plugin forkMode question
Using the clean plugin does seem much better but I could not find any docs on how to drop a folder only files in a folder. -Dave On Fri, Sep 4, 2009 at 7:44 AM, Brett Porter wrote: > > > On 04/09/2009, at 11:33 PM, David Hoffer wrote: > > Do you know of a way, using gmaven, to drop a folder containing files >> and/or >> subfolders? Currently I consider my solution to be a hack because its bad >> enough that the logic of what to cleanup is not in the test case source >> file, but when I have to manually specify each and every file to delete >> it's >> a hack. This will never stay in sync over time. >> >> If I could put all my temp test files/folders in a folder called 'tmp' and >> then just drop 'tmp' using gmaven that's less of a hack. >> >> > I think you'd be better off configuring an instance of the clean plugin > instead of gmaven if all you want to do is delete a directory. It can take > an arbitrary set of files / directories to clean. > > You are right on the lifecyle, I forgot that I had set a phase...I'll >> change >> it to 'test'. I always get confused on this issue...do plugins ALWAYS run >> AFTER the phase they are attached to? >> > > No, they run in that phase, but are added after any already specified (so > after anything built in). > > > - Brett > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: maven-surefire-plugin forkMode question
On 04/09/2009, at 11:33 PM, David Hoffer wrote: Do you know of a way, using gmaven, to drop a folder containing files and/or subfolders? Currently I consider my solution to be a hack because its bad enough that the logic of what to cleanup is not in the test case source file, but when I have to manually specify each and every file to delete it's a hack. This will never stay in sync over time. If I could put all my temp test files/folders in a folder called 'tmp' and then just drop 'tmp' using gmaven that's less of a hack. I think you'd be better off configuring an instance of the clean plugin instead of gmaven if all you want to do is delete a directory. It can take an arbitrary set of files / directories to clean. You are right on the lifecyle, I forgot that I had set a phase...I'll change it to 'test'. I always get confused on this issue...do plugins ALWAYS run AFTER the phase they are attached to? No, they run in that phase, but are added after any already specified (so after anything built in). - Brett - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin forkMode question
Do you know of a way, using gmaven, to drop a folder containing files and/or subfolders? Currently I consider my solution to be a hack because its bad enough that the logic of what to cleanup is not in the test case source file, but when I have to manually specify each and every file to delete it's a hack. This will never stay in sync over time. If I could put all my temp test files/folders in a folder called 'tmp' and then just drop 'tmp' using gmaven that's less of a hack. You are right on the lifecyle, I forgot that I had set a phase...I'll change it to 'test'. I always get confused on this issue...do plugins ALWAYS run AFTER the phase they are attached to? -Dave On Fri, Sep 4, 2009 at 12:14 AM, Brett Porter wrote: > > On 04/09/2009, at 4:04 PM, David Hoffer wrote: > > Do you know of any example of using the 'exec plugin from the test phase >> in >> the POM '? >> >> Currently the workaround I have found is to use the GMaven plugin that >> deletes the DB. However I don't have known control over when this >> runs...it >> just happens to work at the moment. >> > > That's an equivalent solution. Adding test inside that > execution is the right place. > > >> BTW, do non-lifecyle bound plugins run in order they are specified in the >> pom? >> > > All plugins are lifecycle bound if they are run via the POM. > > > - Brett > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: maven-surefire-plugin forkMode question
On 04/09/2009, at 4:04 PM, David Hoffer wrote: Do you know of any example of using the 'exec plugin from the test phase in the POM '? Currently the workaround I have found is to use the GMaven plugin that deletes the DB. However I don't have known control over when this runs...it just happens to work at the moment. That's an equivalent solution. Adding test inside that execution is the right place. BTW, do non-lifecyle bound plugins run in order they are specified in the pom? All plugins are lifecycle bound if they are run via the POM. - Brett - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin forkMode question
Do you know of any example of using the 'exec plugin from the test phase in the POM '? Currently the workaround I have found is to use the GMaven plugin that deletes the DB. However I don't have known control over when this runs...it just happens to work at the moment. BTW, do non-lifecyle bound plugins run in order they are specified in the pom? -Dave On Thu, Sep 3, 2009 at 11:40 PM, Brett Porter wrote: > On 04/09/2009, at 3:35 PM, David Hoffer wrote: > > During the setup for the test, actually I do this in the @BeforeClass >> because its expensive, we make some calls into legacy code that creates db >> connections. I need to delete the access db after the test but can't >> because the db connections still exist. >> >> So ideally I need some (tearDown) process to come along after each test >> and >> do a cleanup. Doing this in the AfterClass would be fine but I can't get >> it >> to work...it seems to be the same process as the tests. >> > > It is. > > I think your best alternative is to delete the database using the exec > plugin from the test phase in the POM (which will run after the surefire > tests have concluded). It also means you don't need to fork multiple JVMs > for your tests if you don't want to. > > - Brett > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: maven-surefire-plugin forkMode question
On 04/09/2009, at 3:35 PM, David Hoffer wrote: During the setup for the test, actually I do this in the @BeforeClass because its expensive, we make some calls into legacy code that creates db connections. I need to delete the access db after the test but can't because the db connections still exist. So ideally I need some (tearDown) process to come along after each test and do a cleanup. Doing this in the AfterClass would be fine but I can't get it to work...it seems to be the same process as the tests. It is. I think your best alternative is to delete the database using the exec plugin from the test phase in the POM (which will run after the surefire tests have concluded). It also means you don't need to fork multiple JVMs for your tests if you don't want to. - Brett - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin forkMode question
During the setup for the test, actually I do this in the @BeforeClass because its expensive, we make some calls into legacy code that creates db connections. I need to delete the access db after the test but can't because the db connections still exist. So ideally I need some (tearDown) process to come along after each test and do a cleanup. Doing this in the AfterClass would be fine but I can't get it to work...it seems to be the same process as the tests. -Dave On Thu, Sep 3, 2009 at 11:22 PM, Brett Porter wrote: > If the forkMode is always, the @before/@after should be run for each test > and JVM, but is still before the JVM shuts down. > > What type of cleanup do you need to do after the JVM is shutdown? > > - Brett > > > On 04/09/2009, at 6:15 AM, David Hoffer wrote: > > How does forking work with respect to the @BeforeClass/@AfterClass >> methods? >> My use case is that I have some setup code that creates file/db >> connections >> that are not destroyed until the jvm is shutdown, therefore I can't >> cleanup >> in the @After method. However it doesn't work using >> @BeforeClass/@AfterClass either and I'm clear why. >> >> I tried using all the fork modes with no success. What's the way to run >> tests in one process and then cleanup in another? >> > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: maven-surefire-plugin forkMode question
If the forkMode is always, the @before/@after should be run for each test and JVM, but is still before the JVM shuts down. What type of cleanup do you need to do after the JVM is shutdown? - Brett On 04/09/2009, at 6:15 AM, David Hoffer wrote: How does forking work with respect to the @BeforeClass/@AfterClass methods? My use case is that I have some setup code that creates file/db connections that are not destroyed until the jvm is shutdown, therefore I can't cleanup in the @After method. However it doesn't work using @BeforeClass/@AfterClass either and I'm clear why. I tried using all the fork modes with no success. What's the way to run tests in one process and then cleanup in another? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin and default locale
On 23/04/2009, Jon Bråten wrote: > Is there a way to set the default locale to be used in JUnit tests run by > maven-surefire-plugin? I've tried adding "-Duser.language=nn" and > "-Duser.country=NN" to the maven command issued, but is does not affect the > test runs. > > The issue at hand is, ofcourse, tests failing due to formatting variations > in amounts and alike. It can be discussed wether these tests are useful, and > either way its an alternative to hardcode the locale in the tests > themselves. But still, I'm curious as to why surefire appears to ignore the > locale specified at command line :) > > Anyone? I think that is because Maven runs the tests in a separate (forked) process by default, so the properties are lost. See: http://maven.apache.org/plugins/maven-surefire-plugin/examples/debugging.html Try adding -DforkMode=none and see it that helps. Otherwise see: http://maven.apache.org/plugins/maven-surefire-plugin/examples/system-properties.html which describes how to define system properties in the POM. > Regards, > Jon B > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [maven-surefire-plugin] test in another project
On Sun, Apr 26, 2009 at 5:22 PM, Esteban Dugueperoux wrote: > It is difficult to manage tests in a separate maven project with surefire? My understanding is that it is not difficult. You simply add dependencies in your test project POM and you are set. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [maven-surefire-plugin] test in another project
Hi Grant, I want have tests project apart because EMF generate tests project always in a aside eclipse project. I develop some eclipse plugins and want manage continuous integration with maven, but tricky work is that build metamodel defined by eclipse is very different to maven build metamodel (pom.xml), Eclipse build metamodel (based on ant) is very difficult to manage with continuous integration. Currently I managed build with pde-maven-plugin and continuous integration with hudson, now it miss tests execution. It is difficult to manage tests in a separate maven project with surefire? Grant Rettke a écrit : Why don't you put your tests for the model project within the model project itself? That is the "Maven" way to do it. On Sun, Apr 26, 2009 at 1:25 PM, Esteban Dugueperoux wrote: Hi, I have a EMF (http://www.eclipse.org/modeling/emf/) project composed of several sub-projects : - model project; - edit project; - tests project; I manage these projects with maven and I would like to execute test from tests project according to test phase. How to specify to surefire maven plugin to execute tests from tests project to test code from model project? Thanks. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [maven-surefire-plugin] test in another project
Why don't you put your tests for the model project within the model project itself? That is the "Maven" way to do it. On Sun, Apr 26, 2009 at 1:25 PM, Esteban Dugueperoux wrote: > Hi, > > I have a EMF (http://www.eclipse.org/modeling/emf/) project composed of > several sub-projects : > - model project; > - edit project; > - tests project; > > I manage these projects with maven and I would like to execute test from > tests project according to test phase. How to specify to surefire maven > plugin to execute tests from tests project to test code from model project? > > > Thanks. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- http://www.wisdomandwonder.com/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin configuration for unit/integration tests
I agree: if you haven't changed any code, and you haven't changed any unit tests, then the only tests that need to run are the integration tests that you are changing. If you've made a mistake and have changed application or unit test code, your CI process will (should) pick it up. We use maven code like generate-hbm-files generate-resources [do stuff] run so that we can call mvn clean package -Dgenerate.hbm.files=true or mvn clean package -Dgenerate.hbm.files=false as necessary Kristof Vanbecelaere wrote: > > Maybe I need to rephrase this a bit. Your line of reasoning is absolutely > correct from a process point of view (like a CI build). But rigorously > applying this principle across the board denies developers the comfort of > selectively running subsets of tests. Developer productivity should count > for something as well. > > > Kristof Vanbecelaere wrote: >> >> I disagree. Have you ever written a selenium test? This is trial and >> error. I have not touched any "real" code, only test code. So I know my >> unit tests succeed. All I want to do is run the integration-test phase >> without unit tests. >> >> >> Stephen Connolly-2 wrote: >>> >>> 2008/11/27 Kristof Vanbecelaere >>> >>> Actually, that is the aim. >>> >>> You run all the unit tests to make sure that the code is good enough to >>> try >>> and run the integration tests. >>> >>> If your unit tests fail, your code is broken and you know it, so fix >>> your >>> code. >>> >>> If your unit tests pass, now lets see if it integrates correctly, hence >>> run >>> the integration tests. >>> >>> If the integration tests pass, we can publish the project (i.e. install >>> or >>> deploy to maven repo) >>> >>> This is what the lifecycle is all about... a well defined sequence of >>> phases, all the previous phases must complete successfully before the >>> next >>> phase starts. >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/maven-surefire-plugin-configuration-for-unit-integration-tests-tp20724622p23128862.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven surefire plugin - testFailureIgnore and its behaviour with forkMode
As far as I know, it's not expected behaviour. If you can create a jira issue with a sample project to reproduce this, I'm sure someone can take a look. Also, try version 2.4.3 since that is the latest. Jaikiran wrote: I am using Maven surefire plugin 2.4.2 with the following configurations: maven-surefire-plugin ... false ... always ... I have intentionally set testFailureIgnore=false (i.e. the default value), so that if the test fails the build process fails. However when my tests fail with ERROR, i see that irrespective of this property value, the rest of the build is carried out and the build reports a SUCCESS. A bit of debugging and playing with the forkMode, shows that the testFailureIgnore=false results in the build to fail (which is what i expect) *only* when the forkMode is set to "never". Setting the forkMode to always or once always results in a successful build irrespective of the testFailureIgnore setting. Is this the expected behaviour? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin: run unit tests from classes in a jar, not a directory
Hi Anshul, This is pretty funny ... I wondered the same questions 2 weeks ago :-) ... And I think I can answer since while reading surefire plugin source code, I sadly saw use of directory test suite is hardcoded in SurefirePlugin.constructSurefireBooter() (search use of string "org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite" for example) Worst, even if you create your own surefire test plugin, I am not really sure you can say maven to plug your plugin instead of surefire one on the test execution phase. Would be really nice to have the string below being parameterizable in surefire properties :-( (Note: since my searches was 2 weeks ago, I was relying on surefire 2.2 plugin ... not 2.3 bundled with maven 2.1.0 :-)) Hope this helps Frederic 2009/3/27 Anshul Jaiswal > I was able to get this to work by modifying the sure-fire plugin source. I > updated AbstractDirectoryTestSuite.collectTests() to be protected. And I > over-rode that method in JUnit4DirectoryTestSuite to list all the jars from > the class path and search for unit tests within them adding the discovered > unit tests to the list of collected tests. It does seem to work. > > I guess, if SurefirePlugin, exposed the name of junit4DirectoryTestSuite as > a parameter, like it exposes the testNG and junit artifact names. I would > have been able to accomplish this without needing any changes to the plugin > codebase. > > In case it's useful for folks, here is the background on why I'm wanting to > do this. > > I'm using this mechanism to be able to create patch projects/artifacts for > artifacts that only include the source for classes that are updated for > that > patch. These patch projects designate the project/artifact being patched as > a parent. The patch project only contains the sources and unit tests for > functionality that has been modified / added in the patch. The jar > generated > by these projects only have the patched classes and I can apply this patch > by placing this jar ahead of the actual artifact's jar, in the classpath, > in > an installation. > > Along with running the unit tests that I have created for the patch, I do > want to be able to run all the unit tests for the project/artifact being > patched, so that I can verify that the entire project continues to work, as > expected, with the changes. Through this mechanism I have that ability. > Ofcourse, the artifact being patched has to export it's to the maven > repository, so that the patch project can depend on it, but that's easy. > > Cheers, > Anshul > > On Thu, Mar 26, 2009 at 1:57 PM, Anshul Jaiswal >wrote: > > > Thanks for your replies, Brett and Stephen! > > > > I was able to use the @RunWith with a Suite subclass that would search > for > > unit tests within jars in the classpath. However, the problem with that > > approach is that all the unit tests run within the same JVM. Whereas we > want > > all the unit tests to be forked, pretty much like forkMode=always. > > > > Looking through the code, it appears to me that I can write my own > subclass > > of org.apache.maven.surefire.suite.AbstractDirectoryTestSuite and > override > > its locateTestSets() method (actually I just want to override > collectTests() > > but that is private) to be able to implement my own test discovery > > algorithm. > > > > However, it's not clear to me how I can get surefire plugin to use my > > subclass instead of the Junit one. I guess I may have to create my own > > surefire-provider? I guess I can do that by starting with (or extending) > the > > junit4 provider. Lets say I do that how, is there a way to get surefire > to > > use my provider instead of junit 4. > > > > Cheers, > > Anshul > > > > > > > > > > On Fri, Mar 20, 2009 at 1:53 PM, Anshul Jaiswal >wrote: > > > >> Folks, > >> > >> The surefire plugin currently supports automatically searching for unit > >> testing classes from a directory. > >> > >> I was wondering if there is way for it to search for unit tests from a > set > >> of jar files instead of a directory. ie., a mechanism where I can > specify a > >> regex pattern for the package and/or class name and it can search > through > >> all the jars in the 'test' scope for classes matching that pattern and > run > >> them. > >> > >> Thanks in advance! > >> Anshul > >> > > > > >
Re: maven-surefire-plugin: run unit tests from classes in a jar, not a directory
I was able to get this to work by modifying the sure-fire plugin source. I updated AbstractDirectoryTestSuite.collectTests() to be protected. And I over-rode that method in JUnit4DirectoryTestSuite to list all the jars from the class path and search for unit tests within them adding the discovered unit tests to the list of collected tests. It does seem to work. I guess, if SurefirePlugin, exposed the name of junit4DirectoryTestSuite as a parameter, like it exposes the testNG and junit artifact names. I would have been able to accomplish this without needing any changes to the plugin codebase. In case it's useful for folks, here is the background on why I'm wanting to do this. I'm using this mechanism to be able to create patch projects/artifacts for artifacts that only include the source for classes that are updated for that patch. These patch projects designate the project/artifact being patched as a parent. The patch project only contains the sources and unit tests for functionality that has been modified / added in the patch. The jar generated by these projects only have the patched classes and I can apply this patch by placing this jar ahead of the actual artifact's jar, in the classpath, in an installation. Along with running the unit tests that I have created for the patch, I do want to be able to run all the unit tests for the project/artifact being patched, so that I can verify that the entire project continues to work, as expected, with the changes. Through this mechanism I have that ability. Ofcourse, the artifact being patched has to export it's to the maven repository, so that the patch project can depend on it, but that's easy. Cheers, Anshul On Thu, Mar 26, 2009 at 1:57 PM, Anshul Jaiswal wrote: > Thanks for your replies, Brett and Stephen! > > I was able to use the @RunWith with a Suite subclass that would search for > unit tests within jars in the classpath. However, the problem with that > approach is that all the unit tests run within the same JVM. Whereas we want > all the unit tests to be forked, pretty much like forkMode=always. > > Looking through the code, it appears to me that I can write my own subclass > of org.apache.maven.surefire.suite.AbstractDirectoryTestSuite and override > its locateTestSets() method (actually I just want to override collectTests() > but that is private) to be able to implement my own test discovery > algorithm. > > However, it's not clear to me how I can get surefire plugin to use my > subclass instead of the Junit one. I guess I may have to create my own > surefire-provider? I guess I can do that by starting with (or extending) the > junit4 provider. Lets say I do that how, is there a way to get surefire to > use my provider instead of junit 4. > > Cheers, > Anshul > > > > > On Fri, Mar 20, 2009 at 1:53 PM, Anshul Jaiswal > wrote: > >> Folks, >> >> The surefire plugin currently supports automatically searching for unit >> testing classes from a directory. >> >> I was wondering if there is way for it to search for unit tests from a set >> of jar files instead of a directory. ie., a mechanism where I can specify a >> regex pattern for the package and/or class name and it can search through >> all the jars in the 'test' scope for classes matching that pattern and run >> them. >> >> Thanks in advance! >> Anshul >> > >
Re: maven-surefire-plugin: run unit tests from classes in a jar, not a directory
Thanks for your replies, Brett and Stephen! I was able to use the @RunWith with a Suite subclass that would search for unit tests within jars in the classpath. However, the problem with that approach is that all the unit tests run within the same JVM. Whereas we want all the unit tests to be forked, pretty much like forkMode=always. Looking through the code, it appears to me that I can write my own subclass of org.apache.maven.surefire.suite.AbstractDirectoryTestSuite and override its locateTestSets() method (actually I just want to override collectTests() but that is private) to be able to implement my own test discovery algorithm. However, it's not clear to me how I can get surefire plugin to use my subclass instead of the Junit one. I guess I may have to create my own surefire-provider? I guess I can do that by starting with (or extending) the junit4 provider. Lets say I do that how, is there a way to get surefire to use my provider instead of junit 4. Cheers, Anshul On Fri, Mar 20, 2009 at 1:53 PM, Anshul Jaiswal wrote: > Folks, > > The surefire plugin currently supports automatically searching for unit > testing classes from a directory. > > I was wondering if there is way for it to search for unit tests from a set > of jar files instead of a directory. ie., a mechanism where I can specify a > regex pattern for the package and/or class name and it can search through > all the jars in the 'test' scope for classes matching that pattern and run > them. > > Thanks in advance! > Anshul >
Re: maven-surefire-plugin: run unit tests from classes in a jar, not a directory
I thought the test-jar packaging was supposed to make this work of course I have not been able to get it to work I've been thinking it's because my tests are all JUnit 4.4 and not 3.8.2... but maybe it's just that surefire does not look inside test-jar dependencies -Stephen 2009/3/21 Brett Porter > I think if you unpack all those JARs into test-classes it will work. > Alternatively you can write test suites that execute the tests from the JARs > without modification to the POM. > > There isn't an option to run them directly from the JAR to my knowledge. > > - Brett > > > On 21/03/2009, at 7:53 AM, Anshul Jaiswal wrote: > > Folks, >> >> The surefire plugin currently supports automatically searching for unit >> testing classes from a directory. >> >> I was wondering if there is way for it to search for unit tests from a set >> of jar files instead of a directory. ie., a mechanism where I can specify >> a >> regex pattern for the package and/or class name and it can search through >> all the jars in the 'test' scope for classes matching that pattern and run >> them. >> >> Thanks in advance! >> Anshul >> > > -- > Brett Porter > br...@apache.org > http://blogs.exist.com/bporter/ > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: maven-surefire-plugin: run unit tests from classes in a jar, not a directory
I think if you unpack all those JARs into test-classes it will work. Alternatively you can write test suites that execute the tests from the JARs without modification to the POM. There isn't an option to run them directly from the JAR to my knowledge. - Brett On 21/03/2009, at 7:53 AM, Anshul Jaiswal wrote: Folks, The surefire plugin currently supports automatically searching for unit testing classes from a directory. I was wondering if there is way for it to search for unit tests from a set of jar files instead of a directory. ie., a mechanism where I can specify a regex pattern for the package and/or class name and it can search through all the jars in the 'test' scope for classes matching that pattern and run them. Thanks in advance! Anshul -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven surefire plugin, TestNG & classpath reference to suiteXmlFile
> Is there a way to configure Maven surefire plugin to lookup TestNG > suiteXmlFile as classpath resource? I'm not aware of such functionality at this time, but you could probably add it by hacking m-s-p in the constructSurefireBooter() method and adding a corresponding configuration option so Surefire knows to "look" for the file in the classpath. Assuming you do this successfully and feel others may benefit from it, please contribute the modification back via JIRA so it can be considered for inclusion in a future version of Maven. Otherwise you will be "stuck" maintaining your own modified m-s-p with this additional feature. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin version 2.3.4 not reporting the @Ignore annotated testcases
Sorry, I made a mistake in the original post. We are using maven-surefire-plugin version 2.4.3. Thanks, -Rakesh Wayne Fay wrote: > > On Fri, Feb 6, 2009 at 12:48 PM, Rakesh Arora > wrote: >> We are using junit 4.4 and maven-surefire-plugin version 2.3.4 >> >> http://jira.codehaus.org/browse/SUREFIRE-303 > > That JIRA indicates it is fixed in Surefire version 2.4, but by your > own admission you are using 2.3.4. I would assume that is the problem. > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > > -- View this message in context: http://www.nabble.com/maven-surefire-plugin-version-2.3.4-not-reporting-the-%40Ignore-annotated-testcases-tp21880371p21914928.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin version 2.3.4 not reporting the @Ignore annotated testcases
On Fri, Feb 6, 2009 at 12:48 PM, Rakesh Arora wrote: > We are using junit 4.4 and maven-surefire-plugin version 2.3.4 > > http://jira.codehaus.org/browse/SUREFIRE-303 That JIRA indicates it is fixed in Surefire version 2.4, but by your own admission you are using 2.3.4. I would assume that is the problem. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin configuration for unit/integration tests
That is why I run the individual tests from my IDE. My IDE (IntelliJ) 2008/11/28 Kristof Vanbecelaere <[EMAIL PROTECTED]> > > Maybe I need to rephrase this a bit. Your line of reasoning is absolutely > correct from a process point of view (like a CI build). But rigorously > applying this principle across the board denies developers the comfort of > selectively running subsets of tests. Developer productivity should count > for something as well. > > > Kristof Vanbecelaere wrote: > > > > I disagree. Have you ever written a selenium test? This is trial and > > error. I have not touched any "real" code, only test code. So I know my > > unit tests succeed. All I want to do is run the integration-test phase > > without unit tests. > > > > > > Stephen Connolly-2 wrote: > >> > >> 2008/11/27 Kristof Vanbecelaere <[EMAIL PROTECTED]> > >> > >> Actually, that is the aim. > >> > >> You run all the unit tests to make sure that the code is good enough to > >> try > >> and run the integration tests. > >> > >> If your unit tests fail, your code is broken and you know it, so fix > your > >> code. > >> > >> If your unit tests pass, now lets see if it integrates correctly, hence > >> run > >> the integration tests. > >> > >> If the integration tests pass, we can publish the project (i.e. install > >> or > >> deploy to maven repo) > >> > >> This is what the lifecycle is all about... a well defined sequence of > >> phases, all the previous phases must complete successfully before the > >> next > >> phase starts. > >> > >> > > > > > > -- > View this message in context: > http://www.nabble.com/maven-surefire-plugin-configuration-for-unit-integration-tests-tp20724622p20730746.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: maven-surefire-plugin configuration for unit/integration tests
Maybe I need to rephrase this a bit. Your line of reasoning is absolutely correct from a process point of view (like a CI build). But rigorously applying this principle across the board denies developers the comfort of selectively running subsets of tests. Developer productivity should count for something as well. Kristof Vanbecelaere wrote: > > I disagree. Have you ever written a selenium test? This is trial and > error. I have not touched any "real" code, only test code. So I know my > unit tests succeed. All I want to do is run the integration-test phase > without unit tests. > > > Stephen Connolly-2 wrote: >> >> 2008/11/27 Kristof Vanbecelaere <[EMAIL PROTECTED]> >> >> Actually, that is the aim. >> >> You run all the unit tests to make sure that the code is good enough to >> try >> and run the integration tests. >> >> If your unit tests fail, your code is broken and you know it, so fix your >> code. >> >> If your unit tests pass, now lets see if it integrates correctly, hence >> run >> the integration tests. >> >> If the integration tests pass, we can publish the project (i.e. install >> or >> deploy to maven repo) >> >> This is what the lifecycle is all about... a well defined sequence of >> phases, all the previous phases must complete successfully before the >> next >> phase starts. >> >> > > -- View this message in context: http://www.nabble.com/maven-surefire-plugin-configuration-for-unit-integration-tests-tp20724622p20730746.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven-surefire-plugin configuration for unit/integration tests
It is possible to just run unit tests or integration tests from a module but it gets messy and over complicated. For example I have projects that separate tests by placing all unit tests in a directory called unit and all integration tests in a directory called it. With such a separation it makes it easier to configure the compile plug-in to exclude tests at certain phases. Likewise the surefire plug-in needs to be configured accordingly with excludes and includes. Then using a profile you can invoke the integration tests which will only run integration tests. This all works fine until you need to generate a site that contains both surefire reports for unit test runs and integration test runs. It's not straightforward as the underlying surefire report plug-in is not as flexible. I'm just waiting for when the next major release of Maven is made as the issue of test separation I believe is addressed -- Robert -Original Message- From: Kristof Vanbecelaere [mailto:[EMAIL PROTECTED] Sent: Friday, November 28, 2008 12:03 AM To: users@maven.apache.org Subject: Re: maven-surefire-plugin configuration for unit/integration tests I disagree. Have you ever written a selenium test? This is trial and error. I have not touched any "real" code, only test code. So I know my unit tests succeed. All I want to do is run the integration-test phase without unit tests. Stephen Connolly-2 wrote: > > 2008/11/27 Kristof Vanbecelaere <[EMAIL PROTECTED]> > > Actually, that is the aim. > > You run all the unit tests to make sure that the code is good enough to > try > and run the integration tests. > > If your unit tests fail, your code is broken and you know it, so fix your > code. > > If your unit tests pass, now lets see if it integrates correctly, hence > run > the integration tests. > > If the integration tests pass, we can publish the project (i.e. install or > deploy to maven repo) > > This is what the lifecycle is all about... a well defined sequence of > phases, all the previous phases must complete successfully before the next > phase starts. > > -- View this message in context: http://www.nabble.com/maven-surefire-plugin-configuration-for-unit-integration-tests-tp20724622p20730286.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-surefire-plugin configuration for unit/integration tests
I disagree. Have you ever written a selenium test? This is trial and error. I have not touched any "real" code, only test code. So I know my unit tests succeed. All I want to do is run the integration-test phase without unit tests. Stephen Connolly-2 wrote: > > 2008/11/27 Kristof Vanbecelaere <[EMAIL PROTECTED]> > > Actually, that is the aim. > > You run all the unit tests to make sure that the code is good enough to > try > and run the integration tests. > > If your unit tests fail, your code is broken and you know it, so fix your > code. > > If your unit tests pass, now lets see if it integrates correctly, hence > run > the integration tests. > > If the integration tests pass, we can publish the project (i.e. install or > deploy to maven repo) > > This is what the lifecycle is all about... a well defined sequence of > phases, all the previous phases must complete successfully before the next > phase starts. > > -- View this message in context: http://www.nabble.com/maven-surefire-plugin-configuration-for-unit-integration-tests-tp20724622p20730286.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-surefire-plugin configuration for unit/integration tests
No, that is the point. Hand-running the integration-test goal runs unit tests as well. John Stoneham wrote: > > > Hand-running the integration-test goal will also work well, if there's > just one. Or a profile would work nicely. > > - John > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/maven-surefire-plugin-configuration-for-unit-integration-tests-tp20724622p20730300.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-surefire-plugin configuration for unit/integration tests
And if you really just want to run integration tests pull these out into their own module which contains no unit tests. Hand-running the integration-test goal will also work well, if there's just one. Or a profile would work nicely. - John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-surefire-plugin configuration for unit/integration tests
>> Unfortunately, I failed to make it work. When running mvn integration-test >> all unit tests get to run before running the integration tests, which is >> not >> really the aim. The idea really is to be able to either run unit tests or >> integration tests but not both at the same time. Any ideas why this fails? >> > > Actually, that is the aim. > > You run all the unit tests to make sure that the code is good enough to try > and run the integration tests. > > If your unit tests fail, your code is broken and you know it, so fix your > code. > > If your unit tests pass, now lets see if it integrates correctly, hence run > the integration tests. > > If the integration tests pass, we can publish the project (i.e. install or > deploy to maven repo) > > This is what the lifecycle is all about... a well defined sequence of > phases, all the previous phases must complete successfully before the next > phase starts. And if you really just want to run integration tests pull these out into their own module which contains no unit tests. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-surefire-plugin configuration for unit/integration tests
2008/11/27 Kristof Vanbecelaere <[EMAIL PROTECTED]> > > Hello, > > I found this interesting blog: > > http://weblogs.java.net/blog/johnsmart/archive/2008/06/unit_tests_are.html > > Unfortunately, I failed to make it work. When running mvn integration-test > all unit tests get to run before running the integration tests, which is > not > really the aim. The idea really is to be able to either run unit tests or > integration tests but not both at the same time. Any ideas why this fails? > Actually, that is the aim. You run all the unit tests to make sure that the code is good enough to try and run the integration tests. If your unit tests fail, your code is broken and you know it, so fix your code. If your unit tests pass, now lets see if it integrates correctly, hence run the integration tests. If the integration tests pass, we can publish the project (i.e. install or deploy to maven repo) This is what the lifecycle is all about... a well defined sequence of phases, all the previous phases must complete successfully before the next phase starts. -Stephen > > I guess the only real way (still) to split off integration tests is to have > a separate module wherein to place these integration tests and put no unit > tests in said module. Or is there? > > Thanks. > -- > View this message in context: > http://www.nabble.com/maven-surefire-plugin-configuration-for-unit-integration-tests-tp20724622p20724622.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: maven-surefire-plugin not excluding tests for test goal
It turns out this was my bug. In my parent (root) pom.xml I have the following to exclude System tests based on a naming convention: org.apache.maven.plugins maven-surefire-plugin 2.3 **/*SystemTest.java However, I had a >maven-surefire-plugin configured in my child project pom.xml where I forgot to exclude system tests the same way. So please ignore my message. Rafael Trestini wrote: > > Farrukh, > > I use these filters in surefire and it works fine. Can you, please, > send us more information about your configuration, like part of pom > where you configure surefire, the name and location of your test > class, versions, etc.. > > Trestini > > On Fri, Nov 7, 2008 at 1:37 PM, Farrukh Najmi > <[EMAIL PROTECTED]> wrote: >> Dear colleagues, >> >> I have a test that was excluded in my maven-surefire-plugin >> configuration. >> When I run the test goal on my pom the excluded test still runs. Is this >> a >> known bug? >> How can I work around it? Thanks. >> > -- View this message in context: http://www.nabble.com/maven-surefire-plugin-not-excluding-tests-for-test-goal-tp20382943p20441039.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-surefire-plugin not excluding tests for test goal
Farrukh, I use these filters in surefire and it works fine. Can you, please, send us more information about your configuration, like part of pom where you configure surefire, the name and location of your test class, versions, etc.. Trestini On Fri, Nov 7, 2008 at 1:37 PM, Farrukh Najmi <[EMAIL PROTECTED]> wrote: > Dear colleagues, > > I have a test that was excluded in my maven-surefire-plugin configuration. > When I run the test goal on my pom the excluded test still runs. Is this a > known bug? > How can I work around it? Thanks. > > -- > Regards, > Farrukh Najmi > > Web: http://www.wellfleetsoftware.com > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Responsibility is the price of freedom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [maven-surefire-plugin] problem with my tests
Guillaume Boucherie wrote: I have a strange behavior with my junit tests. I have a project with multi-modules. When I run the tests individually for module (mvn test) everything is ok. But when I run the tests from the parent pom (mvn test) I have always an error when my program try to parse an xml file. This doesn't immediately ring a bell; it seems impossible to diagnose it based on only this information. Try to create a reduced test case (a zip of minimal Maven projects that reproduce the problem) and file it as a bug. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Surefire Plugin Quick Question
Thanks Guys! testFailureIgnore works nicely. Thanks for the quick reply. Tonté "Mick Knutson" <[EMAIL PROTECTED] l.com> To "Maven Users List" 04/15/2008 01:36 PM cc Subject Please respond to Re: Maven Surefire Plugin Quick "Maven UsersQuestion List" <[EMAIL PROTECTED] he.org> true On Tue, Apr 15, 2008 at 11:28 AM, Tonté Pouncil <[EMAIL PROTECTED]> wrote: > > Hi, > > I am using Maven 2.0.8. How do I enable maven to build successfully even > though I have test failures? > > Thansk! > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ > > This e-mail message, including attachments, may contain confidential, > proprietary, or export controlled information. > Any unauthorized disclosure, distribution, or other use is prohibited, > unless expressly authorized. > If you receive this e-mail in error, please notify the sender, and delete > all copies of the original message from your systems. > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Thanks, Mick Knutson http://www.baselogic.com http://www.blincmagazine.com http://www.linkedin.com/in/mickknutson http://www.djmick.com http://www.myspace.com/mickknutson http://www.myspace.com/BLiNCMagazine http://tahoe.baselogic.com --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Surefire Plugin Quick Question
true On Tue, Apr 15, 2008 at 11:28 AM, Tonté Pouncil <[EMAIL PROTECTED]> wrote: > > Hi, > > I am using Maven 2.0.8. How do I enable maven to build successfully even > though I have test failures? > > Thansk! > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ > > This e-mail message, including attachments, may contain confidential, > proprietary, or export controlled information. > Any unauthorized disclosure, distribution, or other use is prohibited, > unless expressly authorized. > If you receive this e-mail in error, please notify the sender, and delete > all copies of the original message from your systems. > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Thanks, Mick Knutson http://www.baselogic.com http://www.blincmagazine.com http://www.linkedin.com/in/mickknutson http://www.djmick.com http://www.myspace.com/mickknutson http://www.myspace.com/BLiNCMagazine http://tahoe.baselogic.com ---
RE: Maven Surefire Plugin Quick Question
To my knowledge, if you run the tests and there are failures you can't build, although you can get something similar by including "-Dmaven.test.skip=true" on the command line. That skips the tests entirely. -Original Message- From: Tonté Pouncil [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 15, 2008 2:29 PM To: users@maven.apache.org Subject: Maven Surefire Plugin Quick Question Hi, I am using Maven 2.0.8. How do I enable maven to build successfully even though I have test failures? Thansk! -- This message may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived by any transmission to an unintended recipient. If you are not an intended recipient, please notify the sender and delete this message immediately. Any views expressed in this message are those of the sender, not those of any entity within the KBC Financial Products group of companies (together referred to as "KBC FP"). This message does not create any obligation, contractual or otherwise, on the part of KBC FP. It is not an offer (or solicitation of an offer) of, or a recommendation to buy or sell, any financial product. Any prices or other values included in this message are indicative only, and do not necessarily represent current market prices, prices at which KBC FP would enter into a transaction, or prices at which similar transactions may be carried on KBC FP's own books. The information contained in this message is provided "as is", without representations or warranties, express or implied, of any kind. Past performance is not indicative of future returns. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven-surefire-plugin
I came across your mail for providing the classpath argument in surefire
plugin. I am coming across the same need , for adding a dependency in
classpath plus the existing classpath.
Did you come across the workaround , found some maven property to refer
to current classpath? If yes please share.
-Nishant
-Original Message-
From: Guillaume Boucherie [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 26, 2007 9:30 AM
To: Maven Users List
Subject: Re: maven-surefire-plugin
Thanks a lot, I've just tested on my project and it work fine.
--
CletteBou
clettebou.miniville.fr
2007/9/26, Tim Kettler <[EMAIL PROTECTED]>:
>
> Ah ok, that's something different. I understand that you don't want to
> create extra projects for this jars as they probably never will
change.
>
> First I thought you just could place the jars in a directory in your
> project and add system dependendcies to them. But then I realized that
> 'system' is already a scope and thus one can't further limit the scope
> to 'test'. Thinking about this a bit I think 'system' shouldn't be a
> scope at all, it's more of a dependency type.
>
> The only other solution I can think of is to store the jars in a
> repository like directory layout (for example under src/test/testjars)
> and declare this directory as a repository in your pom:
>
>
> my-test-artifact-repository
> file://${basedir}/src/test/testjars
>
>
> and then declare the jars as normal test-scoped dependencies.
>
> -Tim
>
> Guillaume Boucherie schrieb:
> > Oh I'm sorry I'm not clear.
> > In my project I have a functionality that search xml files with the
same
> > name in the classpath and merge it before read it.
> > And to test it I must have jars that just contains xml file, I don't
> want to
> > create a maven project just for this type of jar.
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-surefire-plugin
Hi,
I nearly have the same need but I want to get all the test classpath in
order to launch a new bench.
It looks likes : Runtime.getRuntime().exec("java -cp " + testClasspath +
"...");
Is it possible and how ?
Rémy
Re: maven-surefire-plugin
Thanks a lot, I've just tested on my project and it work fine.
--
CletteBou
clettebou.miniville.fr
2007/9/26, Tim Kettler <[EMAIL PROTECTED]>:
>
> Ah ok, that's something different. I understand that you don't want to
> create extra projects for this jars as they probably never will change.
>
> First I thought you just could place the jars in a directory in your
> project and add system dependendcies to them. But then I realized that
> 'system' is already a scope and thus one can't further limit the scope
> to 'test'. Thinking about this a bit I think 'system' shouldn't be a
> scope at all, it's more of a dependency type.
>
> The only other solution I can think of is to store the jars in a
> repository like directory layout (for example under src/test/testjars)
> and declare this directory as a repository in your pom:
>
>
> my-test-artifact-repository
> file://${basedir}/src/test/testjars
>
>
> and then declare the jars as normal test-scoped dependencies.
>
> -Tim
>
> Guillaume Boucherie schrieb:
> > Oh I'm sorry I'm not clear.
> > In my project I have a functionality that search xml files with the same
> > name in the classpath and merge it before read it.
> > And to test it I must have jars that just contains xml file, I don't
> want to
> > create a maven project just for this type of jar.
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Re: maven-surefire-plugin
i think you should provide more detail... are you saying you just want the file in the test classpath... put it in src/test/resources on the other hand maven projects are easy... and you have release management... versions... tags... why not have a project with the xml in it.. On Wednesday 26 September 2007 20:38, Guillaume Boucherie wrote: > Oh I'm sorry I'm not clear. > In my project I have a functionality that search xml files with the same > name in the classpath and merge it before read it. > And to test it I must have jars that just contains xml file, I don't want > to create a maven project just for this type of jar. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-surefire-plugin
Ah ok, that's something different. I understand that you don't want to
create extra projects for this jars as they probably never will change.
First I thought you just could place the jars in a directory in your
project and add system dependendcies to them. But then I realized that
'system' is already a scope and thus one can't further limit the scope
to 'test'. Thinking about this a bit I think 'system' shouldn't be a
scope at all, it's more of a dependency type.
The only other solution I can think of is to store the jars in a
repository like directory layout (for example under src/test/testjars)
and declare this directory as a repository in your pom:
my-test-artifact-repository
file://${basedir}/src/test/testjars
and then declare the jars as normal test-scoped dependencies.
-Tim
Guillaume Boucherie schrieb:
Oh I'm sorry I'm not clear.
In my project I have a functionality that search xml files with the same
name in the classpath and merge it before read it.
And to test it I must have jars that just contains xml file, I don't want to
create a maven project just for this type of jar.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-surefire-plugin
In your test case you should be able to do this. Enumeration enumeration = getClass().getClassLoader().getResources(resource); HTH Jim On 9/26/07, Guillaume Boucherie <[EMAIL PROTECTED]> wrote: > > Oh I'm sorry I'm not clear. > In my project I have a functionality that search xml files with the same > name in the classpath and merge it before read it. > And to test it I must have jars that just contains xml file, I don't want > to > create a maven project just for this type of jar. > > -- > CletteBou > clettebou.miniville.fr > > > 2007/9/26, Tim Kettler <[EMAIL PROTECTED]>: > > > > Hi, > > > > you want test dependencies. From [1]: > > > > "test - this scope indicates that the dependency is not required for > > normal use of the application, and is only available for the test > > compilation and execution phases." > > > > -Tim > > > > [1] > > > > > http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > > > > Guillaume Boucherie schrieb: > > > Hi, > > > > > > In the maven1 test plugin it's possible to add jar's in the classpath > > with > > > the properties maven.test.classpath > > > Does maven2 surefire plugin provide a way do to the same ? > > > Thanks > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
Re: maven-surefire-plugin
Oh I'm sorry I'm not clear. In my project I have a functionality that search xml files with the same name in the classpath and merge it before read it. And to test it I must have jars that just contains xml file, I don't want to create a maven project just for this type of jar. -- CletteBou clettebou.miniville.fr 2007/9/26, Tim Kettler <[EMAIL PROTECTED]>: > > Hi, > > you want test dependencies. From [1]: > > "test - this scope indicates that the dependency is not required for > normal use of the application, and is only available for the test > compilation and execution phases." > > -Tim > > [1] > > http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > > Guillaume Boucherie schrieb: > > Hi, > > > > In the maven1 test plugin it's possible to add jar's in the classpath > with > > the properties maven.test.classpath > > Does maven2 surefire plugin provide a way do to the same ? > > Thanks > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: maven-surefire-plugin
Hi, you want test dependencies. From [1]: "test - this scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases." -Tim [1] http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html Guillaume Boucherie schrieb: Hi, In the maven1 test plugin it's possible to add jar's in the classpath with the properties maven.test.classpath Does maven2 surefire plugin provide a way do to the same ? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-surefire-plugin
Just add a dependency with scope "test" and it will be added to your test classpath. Hth, Nick Stolwijk Guillaume Boucherie wrote: Hi, In the maven1 test plugin it's possible to add jar's in the classpath with the properties maven.test.classpath Does maven2 surefire plugin provide a way do to the same ? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven-surefire-plugin 2.0 and 2.3 - init phase problem
Thank you Jörg, I have decided to use mechanism, but there is another problems :) How can I use the same classloader during few phases (surefire)? I have experimented with and other tags, but maven-surefire-plugin 2.3 is still use different classloaders. Jörg Schaible wrote: > > vetalok wrote on Friday, July 20, 2007 2:49 PM: > >> It seems since version 2.2 maven-surefire-plugin do not care about >> order of tests: >> (3)**/init/*Data* >> (2)**/api/*1Test.java >> (1)**/api/*2Test.java >> How can I tell to maven to keep the order I writed? >> ( mechanism is unsuitable) >> Someone can help me? > > You should not write tests that rely on a special execution sequence. No > environment running unit tests will ever assure this. > > - Jörg > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/maven-surefire-plugin-2.0-and-2.3---init-phase-problem-tf4116244s177.html#a11709094 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven-surefire-plugin 2.0 and 2.3 - init phase problem
vetalok wrote on Friday, July 20, 2007 2:49 PM: > It seems since version 2.2 maven-surefire-plugin do not care about > order of tests: > (3)**/init/*Data* > (2)**/api/*1Test.java > (1)**/api/*2Test.java > How can I tell to maven to keep the order I writed? > ( mechanism is unsuitable) > Someone can help me? You should not write tests that rely on a special execution sequence. No environment running unit tests will ever assure this. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
