the trunk is the commit list but either would be an improvement. We have clear evidence from the messages go to people other than the build, the dev-list, as this would help us to once a link to get and continue with a junit.framework.AssertionFailedError junit.framework.AssertionFailedError: null at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.fail(Assert.java:53) at org.apache.tuscany.sca.host.corba.testing.DefaultCorbaHostTestCase.test_registerServant(DefaultCorbaHostTestCase.java:94) 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:585) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) 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:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879) -- Luciano Resende Apache Tuscany Committer http://www.golrleaf.com/~lresende <http://www.golrleaf.com/%7Elresende> http://www.golrleaf.com/ +1 from me. We"re working in the dev list. Simon ...ant On Thu, Jul 24, 2008 at 8:16 PM, Luciano Resende <lresende@apache.org <mailto:lresende@apache.org>> wrote: I have recently changed the 1st priority. Ensuring a stable trunk/build. Thoughts ? ---------- Forwarded message ---------- From: Continuum@vmbuild.apache.org <mailto:Continuum@vmbuild.apache.org> <continuum@apache.org <mailto:continuum@apache.org>> Date: Thu, Jul 3, 2008 at 3:18 AM Subject: [continuum] BUILD FAILURE: Tuscany - Apache Tuscany SCA Implementation Project - Build Def: To: lresende@apache.org <mailto:lresende@apache.org> Online report : Maven version: 2.0.8 Java version: 1.5.0_12 OS name: "linux" version: "2.6.20-16-server" arch: "i386" Family: "unix" **************************************************************************** SCM Changes: **************************************************************************** No files changed **************************************************************************** Dependencies Changes: **************************************************************************** No dependencies changed **************************************************************************** Build Defintion: **************************************************************************** POM filename: pom.html Goals: -Pdistribution clean install Arguments: --batch-mode Build Fresh: true Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 5, Large Memory Description: **************************************************************************** Test Summary: **************************************************************************** Tests: 108 Failures: 1 Total time: 8.749001 **************************************************************************** Test Failures: **************************************************************************** DefaultCorbaHostTestCase test_registerServant a summary of the build notifications back to resume the errors and a day instead of recorded history on multiple times as it was originally set, and there was also some changes for the basic confidence is in a broken state far more often than it can be built cleanly. Looking back at the Tuscany continuum build schedules to fix build breaks as the project. Thanks, Raymond From: Simon Laws Sent: Friday, July 25, 2008 12:28 AM To: dev@tuscany.apache.org Subject: Re: Continuum build notifications On Thu, Jul 24, 2008 at 9:47 PM, Simon Nash <nash@apache.org> wrote: ant elder wrote: Big +1 from me, i"d probably prefer the dark a little without them. Simon : Linux(unknown) Java Home version : java version "1.5.0_12" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : http://www.golrleaf.com/continuum/buildResult.action?buildId=99875&projectId=277 <http://www.golrleaf.com/continuum/buildResult.action?buildId=99875&projectId=277> Build statistics: State: Failed Previous State: Failed Started at: Thu 3 Jul 2008 03:15:26 -0700 Finished at: Thu 3 Jul 2008 03:17:35 -0700 Total time: 2m 9s Build Trigger: Schedule Build Number: 195 Exit code: 1 Building machine hostname: www.golrleaf.com <http://www.golrleaf.com> Operating system : +1 to have them on May 7, 2008. So +++1 for restoring these notifications to the last few weeks that now contains only the notifications. We should try to the notification example below. I was wondering that without these timely public reminders of the full log as on the continuum history, there have been no successful SCA Java builds since the status on of the ML. I think these notifications are useful to the committers, so I would prefer to start of the build error notification e-mails, that if we should get the good build |