> A tweet from the background ... Very welcome.
> The email reports that nag us on Cocoon and Forrest > are very hard for me to follow. (Please don't stop the nags.) > > I do try to decipher them and even follow through > to the website. However, i inevitably give up and wait. Bummer. Can you point to parts that are confusing? I'd appreciate any feedback on wording, or content, or format, or whatever. > Thank heaven that Stefan Bodewig and Stephen McConnell et al > sometimes send us a fix for our gump descriptor. > These fixes are often obscure. This is something I totally agree upon. An Ant build works for user's, but fail on Gump, 'cos Gump is "more strict" or in a clean environment, or in it's environment. I've tried to list (on the www pages) all these things, so folks can compare, but I beleive many folks see that as overkill information/clutter that hinders more than helps. If a dynamic webapp (or more structured/broken static set of pages) could allow users to get answers to their questions (e.g. what CLASSPATH is used, what properties are set) rather than having it all dumped in front of them, I think it'd improve things. > So, please, it is not that we don't care. > > How to ease the confusion, i do not know. I also believe that Gump needs to start being more intelligent about it's builds, and interacting with them. It isn't so hard to detect what is going on inside, and Gump can parse Ant output. A ClassNotFound (when it works for a user) is almost always a missing <depend or <work entry, and Gump could prompt users for this. Heck, Gump ought go and look up the package of the missing class and see if it knows where it ought find it. I think Gump needs to start to parsing the outputs, and talking to the users about them. That, and perhaps we need to work on documenting the XML more clearly (or referencing it more). regards, Adam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
