Hi Stefan, Thanks for your help. However, I don't see how I can debug this without having access to a gump install. There's nothing wrong in the build itself. It just fails on one test.
I believe the error might be due to the fact that Cactus is supposed to be executed on a machine where containers are already installed (in our case at hand, Tomcat 3.3.x). When I run the build locally I have the cactus.home.tomcat3x point to where Tomcat 3.3.x is installed. Whereas in the gump build I'm not sure it's pointing to a real install directory. I think it's point to the directory where Tomcat 3.3.x was built and it may happen that Tomcat build does not have all configuration files set up correctly? I'm really shooting in the dark. It's a pity that http://lsd.student.utwente.nl/gump/jakarta-cactus/jakarta-cactus-sample- servlet-13.html has a pre-req failure as we would have been able to see if it passed the tests fine (it's using Tomcat 4.x and not Tomcat 3.3.x). The other possible reason for failure is because it's running on unix whereas I'm running on windows. I'd need to set up my shell account on cvs.apache.org to try running it there. That'll take me a while to setup. The only issue with all this is that it's quite difficult to do so you have to be really motivated :-) What I mean by this is that most of the time there's a problem with the Cactus build on Gump it's not a problem of Cactus, it's a problem of the Gump build setup itself (at least this is my experience from the past few years Cactus has been building with Gump). Thus I know Cactus is building fine. I just need to make it build with Gump... The biggest problem is that Gump doesn't run the build in the same than projects are running their builds! It's using sysclasspathonly feature and that's not the way it's run by project. Thus lots of Gump build failures are due to this different setup. While I can see the benefit of it, I still also value the simple fact that the build is working. Maybe an alternative would be for Gump to try to run the project using sysclasspatonly first and then if it fails, it will run "normally". The reports would show both outcomes. That would provide useful feedback. Thanks -Vincent > -----Original Message----- > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Sent: 11 March 2004 10:06 > To: [EMAIL PROTECTED] > Subject: Re: How to debug a Gump build problem? > > On Thu, 11 Mar 2004, Vincent Massol <[EMAIL PROTECTED]> wrote: > > > Everything runs fine here. Thus I think it can be caused either by a > > different configuration or by the fact that it runs on a different > > OS. > > It fails on lsd as well as gump.covalent.net, so it fails using Gumpy > or traditional Gump and it fails on Linux as well as Solaris. > > Ooops, I just realized that it hasn't built on the covalent machine. > I think this was due to the fact that the configuration was stalled. > Should build in a few minutes. > > > More specifically: Do we have a shell account with read access to > > the directory where Gump built the project? > > Currently Gump doesn't run on any ASF machine, unless Stefano's > efforts on moof have come further along than I thought. > > Once we have such a beast, things should become fairly easy. > > I'm not in the position to give you access to any of the machines > currently running Gump, not even my private installation, sorry. > > I'm willing to lend a hand and execute whatever you need in my > installation, > <http://cvs.apache.org/~bodewig/gump/jakarta-cactus-sample-servlet- > 12.html> > is the result from last night's run on my machine and in my home dir > on minotaur is a zipped up version of > jakarta-cactus/samples/servlet/target-12. > > Let me know if you need anything else. > > Cheers > > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
