[GUMP-103] design conventions for marking up the gump.model and modifying behaviour

• Type: Task
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: Gump3-alpha-4
• Fix Version/s: Gump3-alpha-4
• Component/s: Python-based Gump
• Assignee: Unassigned
• Reporter: Leo Simons
• Created: 28/Mar/05 07:48
• Updated: 01/May/05 22:16
• Resolved: 01/May/05 22:16

Description

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

Issue Links

• is related to: GUMP-106 gump.plugins.ScriptPlugin component for executing <script/> commands