As we've discussed before...

90% of the time when a project, that has been successfully built, starts failing, it is 'cos of a contract shift (break/change) below it. We proceed to notify the project, but often those folks don't have the Gump itch to root out the cause & zap it.

I think it is time to start to teach Gump the skill of notifying the correct pair. I don't think this will be simple, but I think we can and ought start working on putting the pieces in place to crack it.

Initially, I could see us having a system whereby each 'issue' is unqiuely identified, and stored in a datbase (RDBMS, for us to query) if not JIRA (if not both). I think Gump ought be 'aware' of issues, and notify to all participants (via cross posting), not just single projects.

Then, I think we need to do what (I beleive) Leo suggested, which is output parsing. The really is no reason why we can't parse Ant output (or Maven, or ...) and look for key indicators. We ought be able to match this to Rhino @ Mozilla. Even if we daren't automate the process of 'assigning participation in cause', maybe it could be used to prompt humans to take such action.

[javac] /usr/local/gump/public/workspace/jakarta-bsf/src/org/apache/bsf/engines/javascript/JavaScriptEngine.java:130: call(java.lang.Object,org.mozilla.javascript.Context,org.mozilla.javascript.Scriptable,java.lang.Object,java.lang.Object[]) in org.mozilla.javascript.ScriptRuntime cannot be applied to (org.mozilla.javascript.Context,java.lang.Object,org.mozilla.javascript.Scriptable,java.lang.Object[],<nulltype>)
[javac] retval = ScriptRuntime.call(cx, fun, global, args, null);
[javac]


So, do we start work with RDBMS, and/or attempt to integrate into JIRA/others, or attempt to parse/comprehend outputs?

regards

Adam
-- Have you Gump'ed your code today?
http://gump.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to