Stefan, the other one of my hassles is the gump descriptors for the projects aren't under the projects control/cvs, they're in Gump's. This leads to a lack of knowledge/documentation about the descriptor within the team as it's "Somebody Else's Problem". This limits the knowledge of Gump.
Questions: a) Why isn't Gump a top level jakarta/xml project? b) Why aren't these mailing lists gump-dev or gump-user? c) What determines whether a sourceforge/jakarta project is built by gump? d) What does forrest have to do with Gump? They seem to be unrelated. e) What are the properties of a build that make it 'Gumpable'? e.g. Maven seems to have difficulties here, even though there's an easy process to bootstrap it? Dazed, but not confused (today), -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers Stefan Bodewig <[EMAIL PROTECTED]> 05/07/02 04:40 PM Please respond to "Alexandria Developers List" To: <[EMAIL PROTECTED]> cc: Subject: Re: Found it On Sun, 05 May 2002, Conor MacNeill <[EMAIL PROTECTED]> wrote: > Do you mean reproting the error to the dependency which introduce > the problem? I wonder how feasible it would be and how many false > positives it would generate. I think you can only do it manually and after you've clearly identified which component is responsible - Gump is already doing this for a certain type of build failure in FOP (the second regexp): <nag from="Sam Ruby <[EMAIL PROTECTED]>"> <regexp to="[EMAIL PROTECTED]"/> <regexp pattern="/\[style\] .* java.lang.NullPointerException/" to="[EMAIL PROTECTED]"/> </nag> Maybe we should have done that for Latka after dIon clearly identified it as a Xerces problem, but then again the problem was fixed shortly thereafter. Stefan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
