When I gave the Gumpy on LSD a Java compiler to use, it did a much better
job:
http://lsd.student.utwente.nl/gump/index.html
There are a lot of failures, but I wonder if those are primarily due to CVS
@ SF.net
E.g.:
http://lsd.student.utwente.nl/gump/junit/update/update_junit.html
causes:
http://lsd.student.utwente.nl/gump/jakarta-commons/commons-logging.html
and no doubt many others to fail.
Leo, do you have CVS repository overrides that Gumpy isn't
recognizing/merging? Maybe this gump is just more sensitive that the
traditional one, I did try to code it to be, I just wasn't betting on CVS @
SF.net still being so dodgy.
A list of things TO-DO:
1) Fix the forrest usage, make the output pretty.
2) Fix "cause" so one can easily click to the root cause of a failure.
3) Fix a bug where the ant buildfile isn't being pick up (when not called
build.xml)
4) Add "state" to the dependees list (to get a quick view of if they are all
busted).
5) Look at "module packages" (or overriding modules to be packages, for
Nick/I).
6) Spec out/document the v0.4 workspace [add the new options]
7) Polish the RSS (not terrible at:
http://lsd.student.utwente.nl/gump/index.rss, needs to be configured for
site for the images, and maybe add a graphic).
... and then start working on a "debugging interface". Nick has (correctly)
observed that this site/documentation/interface is top down and design for
reviewing success/configuration, not for debugging failures. I need to allow
quick/easy getting to the problems. That, and the "XREF" section.
Hmm, I don't think Gumpy publishes Jars, nor copes with projects defined at
the workspace level, and I am sure it has some other subtle differences. Any
other things people can see is wrong with this Gump?
See you in a week or so...
regards
Adam
--
Experience Sybase Technology...
http://www.try.sybase.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]