I think the key is that the gump runs as for Gump or Gumpy do *not* contain enough information.
what might work sometimes is (pattern) matching the <package/> statements of the dependencies against the errors produced by javac or unit tests, and cvs history.
that would've caught the xml-batik error, I think. I mean,
[javac] /data/gump/xml-batik/sources/org/apache/batik/script/rhino/BatikSecurityController.java:69: org.apache.batik.script.rhino.BatikSecurityController is not abstract and does not override abstract method callWithDomain(java.lang.Object,org.mozilla.javascript.Context,org.mozilla.javascript.Callable,org.mozilla.javascript.Scriptable,org.mozilla.javascript.Scriptable,java.lang.Object[]) in org.mozilla.javascript.SecurityController
[javac] public class BatikSecurityController extends SecurityController {
is clearly showing to any human programmer that whatever produces the
org.mozilla.javascript
package is the problem, since BatikSecurityController.java presumably didn't change since the previous build yet started causing a compilation failure.
you'd need to be pretty intelligent about parsing the error message though. But it seems to be there in some way, without needing /that/ many statistics.
-- cheers,
- Leo Simons
----------------------------------------------------------------------- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles & Opinions -- http://articles.leosimons.com/ ----------------------------------------------------------------------- "We started off trying to set up a small anarchist community, but people wouldn't obey the rules." -- Alan Bennett
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
