Gump オブジェクトモデル
Apache Gump のデータ定義は、開発者が実行するであろう様々なロールの前後に纏められています。 The overall approach is that elements (例： project 定義) can be repeated in multiple contexts (e.g., modules, profiles, and workspaces), with definitions in "higher" level constructs extending or overriding the previous definitions.
workspace の拡張、オーバーライドの方法は極めてシンプルです。もし、２つの似通った要素（例：project）が あって "name" 属性 が同一値を指している状態で存在していれば、それらは重ね合わせ処理されます。属性の重ね合わせは、同一属性の前の値に対するオーバーライドのような結果になります。要素の重ね合わせは、連結の結果になります。これらのルールにより、容易に、ターゲットのオーバーライド、依存関係の追加が可能となります。
将来の探査用の領域として "anti-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.
workspace 定義は、絶対パス名及び他のマシンの具体的な情報が含まれている場所のみに置かれるべきです。
by Sam Ruby
