GumpDevelopment/Changes/MetadataProcessing

There are two aspects to working with metadata in Gump.

• Loading Metadata (from a local repository and/or from remote URLs)
• 'Completeing' metadata to Objects.
  
  

Loading Metadata

Metadata is loaded using tasks (not yet multithreaded) that fetch the data, parse the XML into a DOM, and then 'resolve' (for want of a better word) the XML into ModelObjects (e.g. Workspace/Profile/Module/Project, etc.)

Attempts are made to resolve URL links to metadata using the 'base' of the current XML document. Attempts are made to resolve object for the DOM metadata using the parent object to determine what those might be.

Basically the workspace and profile becme objects that create module and/or project objects for all <module and <project elements (they also weave them into a workspace tree of objects).

Completing Metadata

Once loaded the objects are requested to 'complete themselves', which involves resolving variables (like @@DATE@@) and includes creating sub-objects for things like <jars and <work, etc.

Another aspect of 'completion' is to wire all the pieces togeter, so the model objects are fully usable at the higher level. Once 'complete' there ought be the correct memory maps for project inter-dependencies, and so forth.

Making Changes

Adding new capabilities (or changing existing) to this area typically means working on the content of the gump.model modules, and adding unit tests to gump/test/model.py (after adding XML to gump/test/resources).