Differences between revisions 1 and 2
Revision 1 as of 2004-03-07 17:13:13
Size: 1503
Editor: 1Cust43
Comment:
Revision 2 as of 2004-03-07 17:24:36
Size: 1718
Editor: 1Cust43
Comment:
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
 * A GumpRun is build using a pattern match expression against project names.  * 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.)
Line 9: Line 21:
-= GumpRun =-

Contains the list of projects expanded from the passed in expressions (or 'all'), but also contains the 'build sequence' for that list (the tree of things to build to complete that list) and the modules that intersects with. This becomes the 'work order' for a run.

-= Annotatable =-

Can contain a list of 'info', 'warn', 'error' text messages.

-= Workable =-

Can be worked on (typically by

-= FileHolder =-

Can contain a list of file references (directories or files).

-= Stateful =-

Holds 'state' (succeeded, failed) and 'reason' (if not Unset, e.g. 'build failed').

-= State Propogation =-
= State Propogation =

-= 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)