Differences between revisions 2 and 3
Revision 2 as of 2004-03-07 17:24:36
Size: 1718
Editor: 1Cust43
Revision 3 as of 2004-03-07 17:31:07
Size: 1716
Editor: 1Cust43
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
-= GumpInternals =- = GumpInternals =


Processing Steps:

  • The GumpMetadata is loaded (via file/HTTP) and 'completed' into the GumpModel

  • The GumpModel is a tree of a workspace containing modules, which contain projects

  • Projects in the tree are linked (bi-directionally) via dependencies
  • A GumpRun is build using a pattern match expression against project names, which contains the build sequence [of modules/projects].

  • ["Packages"] are determined (and their state set to 'complete' or 'failed').
  • For updates, the build sequence of modules is traversed, any in a good state are cvs|svn updated. Any failures are propogated (see below).
  • The build sequence of projects is traversed, any in a good state have the following:
  • * The pre-build steps are:
  • ** Create directories for <mkdir

  • ** Delete directories for <delete Note: Currently disabled for security.

  • * Build using script or ant (or maven). Classpath is determined/set.
  • * State is set/propogated based of exit code.
  • * The post-build stesp are:
  • ** Check all outputs (jars/licenses) exist, or set state to failed.
  • ** Copy outputs to Jar repository
  • ** 'List' certain files (maven log, junit reports, etc.)

State Propogation

If a project's "state" is set to smething bad (e.g. failed) then that propogates "up" to all "dependees" of that project that do not already have a bad state. When state propogates it changes (from whatever negative) to "prerequisite failed", and the originating project becomes the ["Cause"] for these projects.

If a module's state is set to something bad (failed) then that propogates down to all it's projects, and in turn 'up' (to dependees of those projects). A module can be a ["Cause"].

GumpInternals (last edited 2009-09-20 23:49:22 by localhost)