Re: Fwd: [GUMP@vmgump]: Project turbine-core (in module turbine-core) failed
On 2011-04-01, Thomas Vandahl wrote: On 01.04.11 06:05, Stefan Bodewig wrote: OK, the way Gump works it means Turbine must be built before Torque, so we must make torque-generator depend on turbine-core (and obviously remove the torque dependencies from turbine-core). We'll also need to check whether any of Turbine's dependencies depend on Torque themselves. I'll take care of this. I'm not a big fan of this solution. Such helper constructs tend to complicate things and some day nobody will remember what it was meant for in the first place. There used to be a commons-xxx-2.x dependency in Gump where some incompatible change had been circumvented. Couldn't we do the something similar here? They only work because the old commons artifacts use a different mvn groupd id from the new ones. In commons land it looks as if the consensus was to change the package name and the artifactId in the future. I think this is because it is pretty likely that projects end up with two different major versions of the same commons roject via transitive dependencies. Generally this won't be the case for other projects. Secondly this means Torque 3.x will be downloaded from Maven central and put into the local repository. Given that Torque4 seems to be known to be incompatible to 3.x (I assume this is intentional) this may be a good It sure is. What is the general idea of Gump to handle incompatible API changes? It really doesn't have a solution for that. It's inital idea has been that APIs never change in backwards incompatible ways and it has never started to accept that reality is different. So far we've dealt with it using the kind of hacks you've seen above. Gump development is slow. thing so I'd live with it (the alternative would be to use a separate local repository). How would the local repository help here? I guess it could help me with fulcrum-quartz as well. A separate local repository only means you get your own copy of local maven artifacts. If your project builds before one of your dependencies you will get the version you asked for rather than the Gump built one and it will be placed into your own local repository and not become available for all the other projects thta want the same artifact (they'll hopefully run later and get the Gump built one). Stefan - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Fwd: [GUMP@vmgump]: Project turbine-core (in module turbine-core) failed
On 01.04.11 06:05, Stefan Bodewig wrote: Burn a few goats. Done. Big stench. Nothing changed. What now? ;-) OK, the way Gump works it means Turbine must be built before Torque, so we must make torque-generator depend on turbine-core (and obviously remove the torque dependencies from turbine-core). We'll also need to check whether any of Turbine's dependencies depend on Torque themselves. I'll take care of this. I'm not a big fan of this solution. Such helper constructs tend to complicate things and some day nobody will remember what it was meant for in the first place. There used to be a commons-xxx-2.x dependency in Gump where some incompatible change had been circumvented. Couldn't we do the something similar here? Secondly this means Torque 3.x will be downloaded from Maven central and put into the local repository. Given that Torque4 seems to be known to be incompatible to 3.x (I assume this is intentional) this may be a good It sure is. What is the general idea of Gump to handle incompatible API changes? thing so I'd live with it (the alternative would be to use a separate local repository). How would the local repository help here? I guess it could help me with fulcrum-quartz as well. Bye, Thomas. - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Fwd: [GUMP@vmgump]: Project turbine-core (in module turbine-core) failed
Hi General Gump, This problem started all of a sudden. I hoped it would vanish the same way. Unfortunately it doesn't. I have no idea what is going on here. The plugin used to work just fine. Any ideas? (Please copy d...@turbine.apache.org) Bye, Thomas. Original Message Subject: [GUMP@vmgump]: Project turbine-core (in module turbine-core) failed Date: Wed, 30 Mar 2011 12:42:54 UTC From: d...@turbine.apache.org Reply-To: Turbine Developers List d...@turbine.apache.org To: d...@turbine.apache.org To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at general@gump.apache.org. Project turbine-core has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 64 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - turbine-core : A servlet based framework. - turbine-core-test : A servlet based framework. Full details are available at: http://vmgump.apache.org/gump/public/turbine-core/turbine-core/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Optional dependency commons-fileupload prerequisite failed with reason build failed -INFO- Optional dependency httpunit failed with reason build failed -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/turbine-core/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/turbine-core/pom.xml -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/turbine-core/turbine-core/gump_work/build_turbine-core_turbine-core.html Work Name: build_turbine-core_turbine-core (Type: Build) Work ended in a state of : Failed Elapsed: 30 secs Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings /srv/gump/public/workspace/turbine-core/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/turbine-core] M2_HOME: /opt/maven2 - urls[19] = file:/srv/gump/public/workspace/mvnlocalrepo/shared/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar urls[20] = file:/srv/gump/public/workspace/mvnlocalrepo/shared/commons-configuration/commons-configuration/1.4/commons-configuration-1.4.jar urls[21] = file:/srv/gump/public/workspace/mvnlocalrepo/shared/commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.jar urls[22] = file:/srv/gump/public/workspace/mvnlocalrepo/shared/commons-digester/commons-digester/1.8/commons-digester-1.8.jar urls[23] = file:/srv/gump/public/workspace/mvnlocalrepo/shared/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar urls[24] = file:/srv/gump/public/workspace/mvnlocalrepo/shared/commons-beanutils/commons-beanutils-core/1.7.0/commons-beanutils-core-1.7.0.jar urls[25] = file:/srv/gump/public/workspace/mvnlocalrepo/shared/commons-codec/commons-codec/1.3/commons-codec-1.3.jar urls[26] = file:/srv/gump/public/workspace/mvnlocalrepo/shared/commons-jxpath/commons-jxpath/1.2/commons-jxpath-1.2.jar urls[27] = file:/srv/gump/public/workspace/mvnlocalrepo/shared/xerces/xerces/1.2.3/xerces-1.2.3.jar urls[28] = file:/srv/gump/public/workspace/mvnlocalrepo/shared/ant/ant-optional/1.5.1/ant-optional-1.5.1.jar urls[29] = file:/srv/gump/public/workspace/mvnlocalrepo/shared/jdom/jdom/b9/jdom-b9.jar Number of imports: 10 import: org.codehaus.classworlds.Entry@a6c57a42 import: org.codehaus.classworlds.Entry@12f43f3b import: org.codehaus.classworlds.Entry@20025374 import: org.codehaus.classworlds.Entry@f8e44ca4 import: org.codehaus.classworlds.Entry@92758522 import: org.codehaus.classworlds.Entry@ebf2705b import: org.codehaus.classworlds.Entry@bb25e54 import: org.codehaus.classworlds.Entry@bece5185 import: org.codehaus.classworlds.Entry@3fee8e37 import: org.codehaus.classworlds.Entry@3fee19d8 this realm = plexus.core urls[0] = file:/opt/maven2/lib/maven-2.2.1-uber.jar Number of imports: 10 import: org.codehaus.classworlds.Entry@a6c57a42 import: org.codehaus.classworlds.Entry@12f43f3b import: org.codehaus.classworlds.Entry@20025374 import: org.codehaus.classworlds.Entry@f8e44ca4 import: org.codehaus.classworlds.Entry@92758522 import: org.codehaus.classworlds.Entry@ebf2705b import: org.codehaus.classworlds.Entry@bb25e54 import: org.codehaus.classworlds.Entry@bece5185 import: org.codehaus.classworlds.Entry@3fee8e37 import: org.codehaus.classworlds.Entry@3fee19d8 - [INFO] [ERROR] BUILD ERROR [INFO] [INFO]
Re: Fwd: [GUMP@vmgump]: Project turbine-core (in module turbine-core) failed
On 2011-03-31, Thomas Vandahl wrote: This problem started all of a sudden. I hoped it would vanish the same way. Unfortunately it doesn't. vmgump says it has been that way for the last 66 runs. Probably longer since the counter gets reset if Gump doesn't even try to build Turbine because a required dependency failed to build. I have no idea what is going on here. The plugin used to work just fine. Any ideas? Gump will hand out the latest Torque jars, i.e. torque-runtime-4.0-alpha1-SNAPSHOT.jar, torque-generator-4.0-alpha1-SNAPSHOT.jar and torque-templates-4.0-alpha1-SNAPSHOT.jar when asked for Torque. Does the plugin work with these versions? Which of the jars contains org.apache.torque.task.TorqueDataModelTask ? Stefan - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Fwd: [GUMP@vmgump]: Project turbine-core (in module turbine-core) failed
CCed to torque-dev for Thomas Fox to know. On 31.03.11 16:32, Stefan Bodewig wrote: Gump will hand out the latest Torque jars, i.e. torque-runtime-4.0-alpha1-SNAPSHOT.jar, torque-generator-4.0-alpha1-SNAPSHOT.jar and torque-templates-4.0-alpha1-SNAPSHOT.jar when asked for Torque. Does the plugin work with these versions? Which of the jars contains org.apache.torque.task.TorqueDataModelTask It used to be in the Torque generator jar but the Torque generator has been rewritten from the ground up by Thomas Fox and probably the plugin doesn't know about that. Anyhow, Turbine needs the Torque plugin/generator/templates/runtime Version 3.3. The current version is not backwards compatible. What do I have to do to achieve this? Bye, Thomas. - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Fwd: [GUMP@vmgump]: Project turbine-core (in module turbine-core) failed
On 2011-03-31, Thomas Vandahl wrote: CCed to torque-dev for Thomas Fox to know. On 31.03.11 16:32, Stefan Bodewig wrote: Gump will hand out the latest Torque jars, i.e. torque-runtime-4.0-alpha1-SNAPSHOT.jar, torque-generator-4.0-alpha1-SNAPSHOT.jar and torque-templates-4.0-alpha1-SNAPSHOT.jar when asked for Torque. Does the plugin work with these versions? Which of the jars contains org.apache.torque.task.TorqueDataModelTask It used to be in the Torque generator jar but the Torque generator has been rewritten from the ground up by Thomas Fox and probably the plugin doesn't know about that. Anyhow, Turbine needs the Torque plugin/generator/templates/runtime Version 3.3. The current version is not backwards compatible. That's what I thought. What do I have to do to achieve this? Burn a few goats. OK, the way Gump works it means Turbine must be built before Torque, so we must make torque-generator depend on turbine-core (and obviously remove the torque dependencies from turbine-core). We'll also need to check whether any of Turbine's dependencies depend on Torque themselves. I'll take care of this. Secondly this means Torque 3.x will be downloaded from Maven central and put into the local repository. Given that Torque4 seems to be known to be incompatible to 3.x (I assume this is intentional) this may be a good thing so I'd live with it (the alternative would be to use a separate local repository). Stefan - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
