My current theory is that there's more than one bug here.
One was the ClassLoader threading issue which is still hard to track down.
There seems to be another issue inside tapestry-ioc related to
instantiating of service implementations. There's code that should be
impossible to trigger that's getting triggered!
On 2/24/07, Adrian Bele <[EMAIL PROTECTED]> wrote:
It's still not working.
Tests run: 762, Failures: 2, Errors: 0, Skipped: 0
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] There are test failures.
[INFO]
------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.BuildFailureException: There are test failures.
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals
(Defa
ultLifecycleExecutor.java:555)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:475)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal
(Defau
ltLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:273)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute
(DefaultLi
fecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAcces
sorImpl.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.MojoFailureException: There are test
failures
.
at org.apache.maven.plugin.surefire.SurefirePlugin.execute
(SurefirePlugi
n.java:428)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo
(DefaultPlugi
nManager.java:412)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals
(Defa
ultLifecycleExecutor.java:534)
... 16 more
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 1 minute 37 seconds
[INFO] Finished at: Sun Feb 25 02:35:47 CET 2007
[INFO] Final Memory: 8M/30M
[INFO]
------------------------------------------------------------------------
On 2/24/07, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
>
> We were seeing what looks like the same thing on the Bamboo CI server.
>
> I thing I found the problem, a race condition involving non-threadsafe
> code inside ClassLoader.getResources(). I've added a bunch of extra
> synchronizes and that may have fixed the problem. Try the 5.0.2 code
> (in SVN trunk).
>
> On 2/24/07, Adrian Bele <[EMAIL PROTECTED]> wrote:
> > Can anybody helpme with this build?
> >
> > Thanks,
> > Adrian
> >
> > D:\mywork\src\tapestry5\tapestry-core\trunk>mvn clean install
> > -Dskip-integration
> > =true
> > [INFO] Scanning for projects...
> > [INFO]
> > --------------
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
