Mailing-List: contact general-help@gump.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Gump code and data" <general@gump.apache.org>
From: "Vincent Massol" <vmassol@pivolis.com>
To: "'Gump code and data'" <general@gump.apache.org>
Subject: RE: How to debug a Gump build problem?
Date: Thu, 11 Mar 2004 10:52:13 +0100
Message-ID: <09f801c4074e$87c9cf50$2502a8c0@vma>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <m31xnz3efh.fsf@bodewig.bost.de>
Importance: Normal


> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@apache.org]
> Sent: 11 March 2004 10:45
> To: general@gump.apache.org
> Subject: Re: How to debug a Gump build problem?
> 
> On Thu, 11 Mar 2004, Vincent Massol <vmassol@pivolis.com> wrote:
> 
> > 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).
> 
> Fails on my machine as well.
> 
> I wonder why jstl-jsp-12 builds for me but not on LSD, wait, it also
> fails on "traditional" Gump but the jar is created before the build
> fails and thus the depending projects can use it.  Does Gumpy discard
> the generated jars of a failed build?
> 
> > 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.
> 
> If this really turns out to be the problem, than it indicates that one
> of the components you depend on has broken its contracts.

Or that there is a configuration issue (coming either from Cactus or
from Tomcat)...
 
> 
> > 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.
> 
> Sure.  This is part of the idea set on how to determine who is
> responsible for a failing build.

cool

> 
> But "ParsingException: Not a valid response [401 Unauthorized]" looks
> strange, I'll try to debug this a little further.

No this is normal. This comes from Cactus itself and indicates the
Cactus client side parts has not successfully authorized itself against
the server side (running inside Tomcat 3.3.x). As part of the its test
Cactus provides a tomcat users file for authorizations.

What would be very useful is to check the /tmp directory. There should a
cactus/ directory containing useful information to know what happened.
This is where cactus installs a temporary Tomcat instance.

Thanks
-Vincent


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org