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]
