It seems the cvs output was big. Continuum allow only 1024 caracters. If you don't want to see it an other time, you can increase the length of the COMMAND_OUTPUT field in your db.
Emmanuel [EMAIL PROTECTED] a écrit :
I searched in JIRA but I could not find a entry that describes the problem.Here you can see a snippet from the logs: 276440818 [pool-1-thread-1] WARN org.apache.maven.continuum.scm.ContinuumScm:default - Provider message: The cvs command failed. 276440850 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.BuildController:default - Merging SCM results 276440896 [Thread-6] ERROR org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:build-project - Error executing task edu.emory.mathcs.backport.java.util.concurrent.ExecutionException: javax.jdo.JDOFatalUserException: Attempt to store value "cvs server: src/...CheckBox.java is no longer in the repository cvs server: src/...ResearchConstants.java is no longer in the repository cvs update: move away src/...Model.java; it is in the way . . [snip] . cvs server: src...Researcj.java is no longer in the repository cvs server: src/...Something.java is no longer in the repository " in column "COMMAND_OUTPUT" that has maximum length of 1024. Please correct your data! at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.getResult(FutureTask.java:299) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.get(FutureTask.java:118) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.waitForTask(ThreadedTaskQueueExecutor.java:159) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:127) Caused by: javax.jdo.JDOFatalUserException: Attempt to store value "cvs server: src/...Box.java is no longer in the repository cvs server: src...Constants.java is no longer in the repository . . [snip] . cvs update: move away src/...Panel.java; it is in the way " in column "COMMAND_OUTPUT" that has maximum length of 1024. Please correct your data! at org.jpox.store.rdbms.mapping.CharRDBMSMapping.setString(CharRDBMSMapping.java:214) at org.jpox.store.mapping.SingleFieldMapping.setString(SingleFieldMapping.java:203) at org.jpox.store.rdbms.fieldmanager.ParameterSetter.storeStringField(ParameterSetter.java:122) at org.jpox.state.StateManagerImpl.providedStringField(StateManagerImpl.java:2757) at org.apache.maven.continuum.model.scm.ScmResult.jdoProvideField(ScmResult.java) at org.apache.maven.continuum.model.scm.ScmResult.jdoProvideFields(ScmResult.java) at org.jpox.state.StateManagerImpl.provideFields(StateManagerImpl.java:3115) at org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:252) at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2519) at org.jpox.store.StoreManager.insert(StoreManager.java:920) at org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3667) at org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3646) at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1198) at org.jpox.AbstractPersistenceManager.makePersistentInternal(AbstractPersistenceManager.java:1243) at org.jpox.store.mapping.PersistenceCapableMapping.setObject(PersistenceCapableMapping.java:450) at org.jpox.store.rdbms.fieldmanager.ParameterSetter.storeObjectField(ParameterSetter.java:144) at org.jpox.state.StateManagerImpl.providedObjectField(StateManagerImpl.java:2771) at org.apache.maven.continuum.model.project.BuildResult.jdoProvideField(BuildResult.java) at org.apache.maven.continuum.model.project.BuildResult.jdoProvideFields(BuildResult.java) at org.jpox.state.StateManagerImpl.provideFields(StateManagerImpl.java:3115) at org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:252) at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2519) at org.jpox.store.StoreManager.insert(StoreManager.java:920) at org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3667) at org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3646) at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1198) at org.jpox.AbstractPersistenceManager.makePersistent(AbstractPersistenceManager.java:1261) at org.codehaus.plexus.jdo.PlexusJdoUtils.makePersistent(PlexusJdoUtils.java:175) at org.apache.maven.continuum.store.JdoContinuumStore.makePersistent(JdoContinuumStore.java:1000) at org.apache.maven.continuum.store.JdoContinuumStore.addBuildResult(JdoContinuumStore.java:438) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.makeAndStoreBuildResult(DefaultBuildController.java:715) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.checkScmResult(DefaultBuildController.java:821) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:122) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:619) -----Ursprüngliche Nachricht-----Von: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 12. Dezember 2007 20:52An: continuum-users@maven.apache.org Betreff: Re: AW: Wrong build status in Project Group Summary I think it is already closed but I'm not sure. I'd like to review all the db tiers in the next version to minimize wrong informations in pages. Emmanuel [EMAIL PROTECTED] a écrit :Hi I now found out why this happens.I have a build schedule that just runs fine once a day. Second I have a build that runs every 5 minutes, but stopps silencliy, without any addition to the logs.So the state is set to error but nothing found in the build log which confused me. The fively build stopps because of this: http://www.nabble.com/Error-caused-by-cvs--22it-is-in-the-way-22-to539 1959s177.html Can you please take a look at this? Is this bug already closed ? Greetings Manuel -----Ursprüngliche Nachricht----- Von: Renz, Manuel Gesendet: Montag, 10. Dezember 2007 15:30 An: continuum-users@maven.apache.org Betreff: AW: Wrong build status in Project Group Summary Hi,the project is marked in error when the project state can't be saved. In next version, I think we'll remove this project state and use only the latest build result instead.Hm, that's strange cause for the the first time I load the Project Group Summary it shows the buildstate correct. And the second time it looses the state and shows the "build in Error" -----Ursprüngliche Nachricht----- Von: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 30. November 2007 16:07 An: continuum-users@maven.apache.org Betreff: Re: Wrong build status in Project Group Summary [EMAIL PROTECTED] a écrit :Hi, currently I have a strange error with the displaying of the build status in the continuum web interface. I uploaded some screenshots to my old opera profile, which I never used but this was the shortest way to get them up somewhere. The mail was too large for the mailinglist. http://my.opera.com/pfuschi/albums/Just take a look at the screenshots.In continuum-1.jpg you learn that 3+1 = 5 ;-)Yes, and it is "normal" ;) you must read it like that:3 projects in success + 1 project in failure + 1 project not built yet (isn't in success/failure/error) = 5in continuum-2.jpg it is a total mess. The 4 success and 1 failed build, which you can see at the top of the screenshot, would be the right set of states...File an issue and we'll look at it.continuum-3.jpg is the real build result of the first project that is in "Error" state (see in continuum-2.jpg) continuum-4.jpg is the real build result of the second project that is in "Error" state (see incontinuum-2.jpg)the project is marked in error when the project state can't be saved. In next version, I think we'll remove this project state and use only the latest build result instead. EmmanuelI'm using continuum 1.1 final. Greetz Manuel -- T-Systems Business Services GmbHApplication Service Center ISW Auto + MI 1 Fasanenweg 5, 70771 Leinfelden-Echterdingen+49 711 972-44092 (Tel.) E-Mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> Internet: http://www.t-systems.de <http://www.t-systems.de/> T-Systems Business Services GmbHAufsichtsrat: RenéObermann (Vorsitzender) Executive Committee: Helmut Binder*, Albert Henn*, Olaf Heyden, Katrin Horstmann, Ulrich Kemp*, Wilfried Peters*, Dr. Herbert Schaaff, Zvezdana Seeger Handelsregister: Amtsgericht Bonn HRB 6787Sitz der Gesellschaft: Bonn WEEE-Reg.-Nr. DE50335567* Geschäftsführer gem. §35 GmbHGNotice: This transmittal and/or attachments may be privileged orconfidential. If you are not the intended recipient, you are hereby notified that you have received this transmittal in error; any review, dissemination, or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you. T-Systems -Business flexibility
