Gump Object Model
The data definitions for Gump are organized around the various roles a developer may perform. The overall approach is that elements (e.g. project definitions) can be repeated in multiple contexts (e.g., modules, profiles, and workspaces), with definitions in "higher" level constructs extending or overriding the previous definitions.
The way extending or overriding works is quite simple. If two like kind elements (e.g., project) are located with the same value for the "name" attribute, they are combined. Combining of attributes results in like named attributes overriding previous values. Combining of elements results in concatenation. These rules allow for the easy overriding of a target and the adding of a dependency.
An area for future exploration is "anti-elements", which cancel out the effect of other elements
An area where designers of XML DTDs have differing opinions is whether a given piece of information should be modeled as an attribute or an element. A design goal of Gump was to try to reinvent as little as possible - resulting in a bit of inconsistency. Project definitions are done in a style reminiscent of Ant - with element and attribute names chosen to match whenever possible. Repository definitions were done in a style consistent with Alexandria. In a few cases, information can be represented as either a nested element or an attribute - this was generally done to make that piece of information easier to override.
One special global substutition is made - the string @@DATE@@ is replaced with the current date in yyyyMMdd format whenever it occurs in any attribute value
The subsections below represent a "bottoms up" introduction to the individual XML data elements, and contain links to more full descriptions
project
A project represents the unit of integration for Gump. It could represent a buildable project, or an installable package. Its primary roles are to be a target of a dependency or the provider of jars and/or other source files.
In the case of buildable projects, project definitions contain values for properties and the dependencies are used to construct the classpath.
Note the project definitions contain the names of the jar or jars that they export. Consuming projects simply name the projects that they depend on.
module
A module is a collection of projects that are physically stored in a single repository. Due to the way that Gump will combine definitions, a module definition can be spread across multiple files.
While a module references a repository, it can also contain prefixes and suffixes that modify the value of the CVSROOT used.
repository
A repository specifies where modules can physically be located. In the case of cvs (the only option supported at the present time), it contains the information used to form the CVSROOT used on checkout and update commands.
profile
A profile is a collection of projects and repositories that are logically to be considered a unit. A profile can provide a consistent set of installable dependencies, or tagged versions of cvs modules to be used.
workspace
A workspace defines the ultimate word as to what projects and repositories are to be used, and the options (e.g., properties, tags, targets, and dependencies) are to be used to build.
A workspace definition should also be the only place where absolute path names and other machine specific information is contained.
by Sam Ruby
