You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stanbol.apache.org by Rupert Westenthaler <ru...@gmail.com> on 2011/06/26 18:32:25 UTC
Timeouts of Jenkins builds
Hi all
Most of the recent builds timed out after one hour while building one
of the launchers.
In build 238 and 239 it was the full launcher.
In build 241 and 243 it was the stateless launcher.
Build 240 was successful and 242 stopped before building the launcher.
The logs always end with the statement
[JENKINS] Archiving
/home/hudson/hudson-slave/workspace/stanbol-trunk-1.6/trunk/launchers/stateless/target/org.apache.stanbol.launchers.stateless-0.9-SNAPSHOT.jar
to /home/hudson/hudson/jobs/stanbol-trunk-1.6/modules/org.apache.stanbol$org.apache.stanbol.launchers.stateless/builds/2011-06-26_15-03-01/archive/org.apache.stanbol/org.apache.stanbol.launchers.stateless/0.9-SNAPSHOT/org.apache.stanbol.launchers.stateless-0.9-SNAPSHOT.jar
in case of the stateless launcher or
[JENKINS] Archiving
/home/hudson/hudson-slave/workspace/stanbol-trunk-1.6/trunk/launchers/full/target/org.apache.stanbol.launchers.full-0.9-SNAPSHOT.jar
to /home/hudson/hudson/jobs/stanbol-trunk-1.6/modules/org.apache.stanbol$org.apache.stanbol.launchers.full/builds/2011-06-22_11-03-55/archive/org.apache.stanbol/org.apache.stanbol.launchers.full/0.9-SNAPSHOT/org.apache.stanbol.launchers.full-0.9-SNAPSHOT.jar
in case of the full launcher
For me that looks like there is some issue while copying the created
jars to some archive with the build artifacts. However I have no Idea
why this could case the timeout.
best
Rupert
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: Timeouts of Jenkins builds
Posted by Rupert Westenthaler <ru...@gmail.com>.
hi
I think we can move the two Ontonet bundles back into the "kres"
profile until the integration-tests are integrated with the others (as
discussed in http://markmail.org/thread/jmz3d5vvvf43rxux).
I would really like some Jenkins builds to execute the unit tests,
because I would like to know if the fix for the race condition of the
DataFileProvider initialization and the opennlp-ner engine had the
intended effect.
WDYT
Rupert
On Mon, Jun 27, 2011 at 2:46 PM, Fabian Christ
<ch...@googlemail.com> wrote:
> Hi,
>
> yes I have the same problem as Olivier.
>
> Tests in error:
> testGetScopes(org.apache.stanbol.ontologymanager.web.JettyServerTest)
> testRemoval(org.apache.stanbol.ontologymanager.web.JettyServerTest)
>
> I did:
>
> rm ~/.m2/repository/org/apache/stanbol
> mvn clean install
>
> - Fabian
>
> 2011/6/27 Olivier Grisel <ol...@ensta.org>:
>> 2011/6/26 Rupert Westenthaler <ru...@gmail.com>:
>>> Hi all
>>>
>>> Most of the recent builds timed out after one hour while building one
>>> of the launchers.
>>> In build 238 and 239 it was the full launcher.
>>> In build 241 and 243 it was the stateless launcher.
>>> Build 240 was successful and 242 stopped before building the launcher.
>>>
>>> The logs always end with the statement
>>>
>>> [JENKINS] Archiving
>>> /home/hudson/hudson-slave/workspace/stanbol-trunk-1.6/trunk/launchers/stateless/target/org.apache.stanbol.launchers.stateless-0.9-SNAPSHOT.jar
>>> to /home/hudson/hudson/jobs/stanbol-trunk-1.6/modules/org.apache.stanbol$org.apache.stanbol.launchers.stateless/builds/2011-06-26_15-03-01/archive/org.apache.stanbol/org.apache.stanbol.launchers.stateless/0.9-SNAPSHOT/org.apache.stanbol.launchers.stateless-0.9-SNAPSHOT.jar
>>>
>>> in case of the stateless launcher or
>>>
>>> [JENKINS] Archiving
>>> /home/hudson/hudson-slave/workspace/stanbol-trunk-1.6/trunk/launchers/full/target/org.apache.stanbol.launchers.full-0.9-SNAPSHOT.jar
>>> to /home/hudson/hudson/jobs/stanbol-trunk-1.6/modules/org.apache.stanbol$org.apache.stanbol.launchers.full/builds/2011-06-22_11-03-55/archive/org.apache.stanbol/org.apache.stanbol.launchers.full/0.9-SNAPSHOT/org.apache.stanbol.launchers.full-0.9-SNAPSHOT.jar
>>>
>>> in case of the full launcher
>>>
>>> For me that looks like there is some issue while copying the created
>>> jars to some archive with the build artifacts. However I have no Idea
>>> why this could case the timeout.
>>
>> I also have timeouts when running the test locally (svn up && mvn
>> clean install at the root of the stanbol folder):
>>
>> For instance:
>>
>> testGetScopes(org.apache.stanbol.ontologymanager.web.JettyServerTest)
>> Time elapsed: 183.194 sec <<< ERROR!
>> java.lang.Exception: Server not ready after 180 seconds
>> at org.apache.stanbol.commons.testing.stanbol.StanbolTestBase.waitForServerReady(StanbolTestBase.java:168)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
>> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
>> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
>> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
>> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
>> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35)
>> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:146)
>> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
>> at $Proxy0.invoke(Unknown Source)
>> at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:145)
>> at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:87)
>> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
>>
>>
>>
>> --
>> Olivier
>> http://twitter.com/ogrisel - http://github.com/ogrisel
>>
>
>
>
> --
> Fabian
>
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: Timeouts of Jenkins builds
Posted by Enrico Daga <en...@gmail.com>.
Hi all,
I have committed some changes in the unit tests of ontonet that should
solve the timeout problem. The cause was the testing of anonymous and
non existent ontologies when present in a registry configuration. In
this case the IRI mapper does not have the resource locally, and the
ontology manager looks for the public IRIs,
http://ontologydesignpatterns.org/..., which is currently down. So
waits some time before skipping. I have commented those two from the
test registry, so now the process goes on smoothly.
Enrico
On 27 June 2011 19:28, Rupert Westenthaler
<ru...@gmail.com> wrote:
> The newest built succeeded in < 30min so given the limit of 60min it
> seams we are now an the save side.
>
> best
> Rupert
>
> On Mon, Jun 27, 2011 at 3:47 PM, Olivier Grisel
> <ol...@ensta.org> wrote:
>> 2011/6/27 Rupert Westenthaler <ru...@gmail.com>:
>>> Hi
>>>
>>> After looking at the timetable [1] of the last build I made some
>>> modifications [2] that should speedup the build process.
>>
>> Thanks.
>>
>> --
>> Olivier
>> http://twitter.com/ogrisel - http://github.com/ogrisel
>>
>
>
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
>
--
Enrico Daga
--
http://www.enridaga.net
skype: enri-pan
Re: Timeouts of Jenkins builds
Posted by Rupert Westenthaler <ru...@gmail.com>.
The newest built succeeded in < 30min so given the limit of 60min it
seams we are now an the save side.
best
Rupert
On Mon, Jun 27, 2011 at 3:47 PM, Olivier Grisel
<ol...@ensta.org> wrote:
> 2011/6/27 Rupert Westenthaler <ru...@gmail.com>:
>> Hi
>>
>> After looking at the timetable [1] of the last build I made some
>> modifications [2] that should speedup the build process.
>
> Thanks.
>
> --
> Olivier
> http://twitter.com/ogrisel - http://github.com/ogrisel
>
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: Timeouts of Jenkins builds
Posted by Olivier Grisel <ol...@ensta.org>.
2011/6/27 Rupert Westenthaler <ru...@gmail.com>:
> Hi
>
> After looking at the timetable [1] of the last build I made some
> modifications [2] that should speedup the build process.
Thanks.
--
Olivier
http://twitter.com/ogrisel - http://github.com/ogrisel
Re: Timeouts of Jenkins builds
Posted by Rupert Westenthaler <ru...@gmail.com>.
Hi
After looking at the timetable [1] of the last build I made some
modifications [2] that should speedup the build process.
Hopefully this improves the situation
best
Rupert
[1] https://builds.apache.org/job/stanbol-trunk-1.6/248/
[2] http://svn.apache.org/viewvc?rev=1140157&view=rev
On Mon, Jun 27, 2011 at 3:11 PM, Olivier Grisel
<ol...@ensta.org> wrote:
> 2011/6/27 Fabian Christ <ch...@googlemail.com>:
>> Hi,
>>
>> yes I have the same problem as Olivier.
>>
>> Tests in error:
>> testGetScopes(org.apache.stanbol.ontologymanager.web.JettyServerTest)
>> testRemoval(org.apache.stanbol.ontologymanager.web.JettyServerTest)
>>
>> I did:
>>
>> rm ~/.m2/repository/org/apache/stanbol
>> mvn clean install
>
> Indeed that fixes my issue, so it's probably not related to the
> timeout issue Rupert is talking about. No I have extremly slow tests
> such as:
>
> Running org.apache.stanbol.ontologymanager.ontonet.registry.TestRegistry
> INFO [main] (ONManagerImpl.java:308) - id: ontonet
>
> Looks like it's downloading the Internet.
>
> We should not enable any test that depends on Internet resource in the
> maven build. Otherwise the continuous integration tests (and thus
> jenkins) will fail randomly based on Internet and remote resources
> availability and stability.
>
> Having a jenkins build that fails randomly independently of the actual
> state of the code base is a major technical debt we should get rid off
> as soon as possible.
>
> IMHO those test should be deactivated in the short term, and rewritten
> to use only local resources (smallish files distributed in the
> src/test/resources folder of the corresponding modules) in the medium
> term.
>
> --
> Olivier
> http://twitter.com/ogrisel - http://github.com/ogrisel
>
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: Timeouts of Jenkins builds
Posted by Olivier Grisel <ol...@ensta.org>.
2011/6/27 Fabian Christ <ch...@googlemail.com>:
> Hi,
>
> yes I have the same problem as Olivier.
>
> Tests in error:
> testGetScopes(org.apache.stanbol.ontologymanager.web.JettyServerTest)
> testRemoval(org.apache.stanbol.ontologymanager.web.JettyServerTest)
>
> I did:
>
> rm ~/.m2/repository/org/apache/stanbol
> mvn clean install
Indeed that fixes my issue, so it's probably not related to the
timeout issue Rupert is talking about. No I have extremly slow tests
such as:
Running org.apache.stanbol.ontologymanager.ontonet.registry.TestRegistry
INFO [main] (ONManagerImpl.java:308) - id: ontonet
Looks like it's downloading the Internet.
We should not enable any test that depends on Internet resource in the
maven build. Otherwise the continuous integration tests (and thus
jenkins) will fail randomly based on Internet and remote resources
availability and stability.
Having a jenkins build that fails randomly independently of the actual
state of the code base is a major technical debt we should get rid off
as soon as possible.
IMHO those test should be deactivated in the short term, and rewritten
to use only local resources (smallish files distributed in the
src/test/resources folder of the corresponding modules) in the medium
term.
--
Olivier
http://twitter.com/ogrisel - http://github.com/ogrisel
Re: Timeouts of Jenkins builds
Posted by Fabian Christ <ch...@googlemail.com>.
Hi,
yes I have the same problem as Olivier.
Tests in error:
testGetScopes(org.apache.stanbol.ontologymanager.web.JettyServerTest)
testRemoval(org.apache.stanbol.ontologymanager.web.JettyServerTest)
I did:
rm ~/.m2/repository/org/apache/stanbol
mvn clean install
- Fabian
2011/6/27 Olivier Grisel <ol...@ensta.org>:
> 2011/6/26 Rupert Westenthaler <ru...@gmail.com>:
>> Hi all
>>
>> Most of the recent builds timed out after one hour while building one
>> of the launchers.
>> In build 238 and 239 it was the full launcher.
>> In build 241 and 243 it was the stateless launcher.
>> Build 240 was successful and 242 stopped before building the launcher.
>>
>> The logs always end with the statement
>>
>> [JENKINS] Archiving
>> /home/hudson/hudson-slave/workspace/stanbol-trunk-1.6/trunk/launchers/stateless/target/org.apache.stanbol.launchers.stateless-0.9-SNAPSHOT.jar
>> to /home/hudson/hudson/jobs/stanbol-trunk-1.6/modules/org.apache.stanbol$org.apache.stanbol.launchers.stateless/builds/2011-06-26_15-03-01/archive/org.apache.stanbol/org.apache.stanbol.launchers.stateless/0.9-SNAPSHOT/org.apache.stanbol.launchers.stateless-0.9-SNAPSHOT.jar
>>
>> in case of the stateless launcher or
>>
>> [JENKINS] Archiving
>> /home/hudson/hudson-slave/workspace/stanbol-trunk-1.6/trunk/launchers/full/target/org.apache.stanbol.launchers.full-0.9-SNAPSHOT.jar
>> to /home/hudson/hudson/jobs/stanbol-trunk-1.6/modules/org.apache.stanbol$org.apache.stanbol.launchers.full/builds/2011-06-22_11-03-55/archive/org.apache.stanbol/org.apache.stanbol.launchers.full/0.9-SNAPSHOT/org.apache.stanbol.launchers.full-0.9-SNAPSHOT.jar
>>
>> in case of the full launcher
>>
>> For me that looks like there is some issue while copying the created
>> jars to some archive with the build artifacts. However I have no Idea
>> why this could case the timeout.
>
> I also have timeouts when running the test locally (svn up && mvn
> clean install at the root of the stanbol folder):
>
> For instance:
>
> testGetScopes(org.apache.stanbol.ontologymanager.web.JettyServerTest)
> Time elapsed: 183.194 sec <<< ERROR!
> java.lang.Exception: Server not ready after 180 seconds
> at org.apache.stanbol.commons.testing.stanbol.StanbolTestBase.waitForServerReady(StanbolTestBase.java:168)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:146)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
> at $Proxy0.invoke(Unknown Source)
> at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:145)
> at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:87)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
>
>
>
> --
> Olivier
> http://twitter.com/ogrisel - http://github.com/ogrisel
>
--
Fabian
Re: Timeouts of Jenkins builds
Posted by Olivier Grisel <ol...@ensta.org>.
2011/6/26 Rupert Westenthaler <ru...@gmail.com>:
> Hi all
>
> Most of the recent builds timed out after one hour while building one
> of the launchers.
> In build 238 and 239 it was the full launcher.
> In build 241 and 243 it was the stateless launcher.
> Build 240 was successful and 242 stopped before building the launcher.
>
> The logs always end with the statement
>
> [JENKINS] Archiving
> /home/hudson/hudson-slave/workspace/stanbol-trunk-1.6/trunk/launchers/stateless/target/org.apache.stanbol.launchers.stateless-0.9-SNAPSHOT.jar
> to /home/hudson/hudson/jobs/stanbol-trunk-1.6/modules/org.apache.stanbol$org.apache.stanbol.launchers.stateless/builds/2011-06-26_15-03-01/archive/org.apache.stanbol/org.apache.stanbol.launchers.stateless/0.9-SNAPSHOT/org.apache.stanbol.launchers.stateless-0.9-SNAPSHOT.jar
>
> in case of the stateless launcher or
>
> [JENKINS] Archiving
> /home/hudson/hudson-slave/workspace/stanbol-trunk-1.6/trunk/launchers/full/target/org.apache.stanbol.launchers.full-0.9-SNAPSHOT.jar
> to /home/hudson/hudson/jobs/stanbol-trunk-1.6/modules/org.apache.stanbol$org.apache.stanbol.launchers.full/builds/2011-06-22_11-03-55/archive/org.apache.stanbol/org.apache.stanbol.launchers.full/0.9-SNAPSHOT/org.apache.stanbol.launchers.full-0.9-SNAPSHOT.jar
>
> in case of the full launcher
>
> For me that looks like there is some issue while copying the created
> jars to some archive with the build artifacts. However I have no Idea
> why this could case the timeout.
I also have timeouts when running the test locally (svn up && mvn
clean install at the root of the stanbol folder):
For instance:
testGetScopes(org.apache.stanbol.ontologymanager.web.JettyServerTest)
Time elapsed: 183.194 sec <<< ERROR!
java.lang.Exception: Server not ready after 180 seconds
at org.apache.stanbol.commons.testing.stanbol.StanbolTestBase.waitForServerReady(StanbolTestBase.java:168)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:146)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
at $Proxy0.invoke(Unknown Source)
at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:145)
at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:87)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
--
Olivier
http://twitter.com/ogrisel - http://github.com/ogrisel