[Help] Help required to debug a cactus gump build!

Hi, Could someone make available the jakarta-tomcat/ gumpy build directory somewhere (i.e. the /data3/gump/jakarta-tomcat/build/tomcat/ dir)? I need this to continue debugging http://lsd.student.utwente.nl/gump/jakarta-cactus/jakarta-cactus-sample- servlet-12.html Thanks! -Vincent Note1: that

Re: Clarifying some licensing issues for Apache developers

Dirk-Willem van Gulik wrote: On Mar 12, 2004, at 3:18 PM, Stefano Mazzocchi wrote: It would be possible and rather simple to add a list of identifiers for the various licenses (maybe using the OSI urls as URIs?) to the project Aye - or use some of the URI pointers to (our own or OSI)

Re: [Request] Make gump build directories browsable

Vincent Massol wrote: Hi, Would it be possible to make the gump build directories browsable. It's just a pain to debug gump and find where the problem is. Making these directories visible will help a lot. rant I've been trying to debug a cactus gump build problem for a week now with no success.

RE: [Request] Make gump build directories browsable

Thanks Stefano. I have been one of the first adopter of Gump (I have even used it on a big project at work! :-)). I do not wish to depart. However, in the past I had enough energy to keep fixing things even it wasn't easy (like I had to install Gump on my machine, etc). Unfortunately I have

Re: [Request] Make gump build directories browsable

Vincent Massol wrote: Thanks Stefano. I have been one of the first adopter of Gump (I have even used it on a big project at work! :-)). I do not wish to depart. However, in the past I had enough energy to keep fixing things even it wasn't easy (like I had to install Gump on my machine, etc).

Re: [head-up + vote] Gump should identify itself!!

Stefano Mazzocchi wrote: Geir Magnusson Jr wrote: It's not me :) It's gump. People, I propose that Gump should identify itself as Apache Gump rather than with the name of the person that onw the project. Vote? +0. In that I like making it the default and change all the project descriptors,

Re: [Request] Make gump build directories browsable

Vincent Massol wrote: Would it be possible to make the gump build directories browsable. I don't think this is a really good idea for lsd, since the setup over there makes it a little difficult to ensure that private stuff remains private. If someone can write a reasonably secure httpd config

[jira] Created: (GUMP-24) Make gump build directories accessible through web browser

Message: A new issue has been created in JIRA. - View the issue: http://issues.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-24 Here is an overview of the issue:

[jira] Created: (GUMP-25) document actual gump installations

Message: A new issue has been created in JIRA. - View the issue: http://issues.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-25 Here is an overview of the issue:

[jira] Created: (GUMP-30) put installed packages under version control

Message: A new issue has been created in JIRA. - View the issue: http://issues.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-30 Here is an overview of the issue:

[jira] Created: (GUMP-31) cvs dirs should be cleaned every month (or so)

Message: A new issue has been created in JIRA. - View the issue: http://issues.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-31 Here is an overview of the issue:

build of xml-xerces 1 on gump@lsd

Gump is building xml-xerces1 with the CVS tag xerces_j_1 This tag contains the offending source file org.apache.xerces.utils.regex.RegularExpression org.apache.xerces.utils.regex.RegularExpression is in the Attic in CVS HEAD. Do we want to change the definition of the project xerces1 to say

BATCH: All dressed up, with nowhere to go...

Dear Gumpmeisters, The following 9 nags should have been sent G U M P [EMAIL PROTECTED]: webwork/webwork failed [EMAIL PROTECTED]: freemarker/freemarker failed [EMAIL PROTECTED]: jakarta-tapestry/ognl failed [EMAIL PROTECTED]:

[Cactus] Gump build failures for the past 2 weeks

Hi guys, I've finally tracked down the Cactus gump build problem we've been having for the past 2 weeks. It appears to be caused by some change in commons-httpclient. The build is working fine with version 2.0 and failing on some authentication code with a commons-httpclient built from CVS HEAD.