design conventions for marking up the gump.model and modifying behaviour ------------------------------------------------------------------------
Key: GUMP-103 URL: http://issues.apache.org/jira/browse/GUMP-103 Project: Gump Type: Task Components: Python-based Gump Versions: Gump3-alpha Reporter: Leo Simons Fix For: Gump3-alpha A whole bunch of plugins will want to execute commands as part of "building" some project. What should be the workflow inside gump to make that happen? It might make sense to have components like the MkdirPlugin and AntPlugin mark up their commands with the exit code, as well as output log and/or error log. Then there might be a StateDetectionPlugin that looks at the state of all projects after the "builder" plugins are done, and sets a project failure|success|prereq failure state or something like that on the project itself, in addition perhaps having a "blame" list pointing at the commands that failed, sorting that in some logical order (if ant failed due to mkdir failing, blame the mkdir, not ant). There could be several StateDetectionPLugins so we can try out different algorithms in dealing with success/failure. The key bit is to keep the builders and the like simple and preferably very linear in their behaviour, with little branching. The less they have to do, the easier it is to add new ones :-D -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]