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
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
