|
|||||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES | ||||||||||
manifest package contains all classes that comprise the manifest domain of Karma.
See:
Description
| Interface Summary | |
| Manifest | |
| Class Summary | |
| AbstractManifest | General stuff for a manifest. |
| DevelopmentManifest | |
| ManifestCollector | Class that collects all manifests for a WorkingContext. |
| ManifestFactory | Creation factory to be able to create Manifest instances. |
| ManifestHeader | Represents the header of a manifest (its name and type). |
| ManifestLoader | Factory class to create ManifestStructure instances. |
| ManifestStructure | Mapping of a manifest file and its included manifest files (any level deep possible). |
| ReleaseManifest | A ReleaseManifest is created when the Release Manager collects all stable versions of modules. |
| Exception Summary | |
| ManifestException | Exception thrown by the AbstractManifest Domain. |
The manifest package contains all classes that comprise the manifest domain of Karma. The
Manifest is the entry-point.
The structure of a manifest is as follows:
<manifest name="oracle-11i-11.1" version="1-0"> <modules> <module name="framework-services" type="src" location="local-cvs"/> <module name="webapp-usermanagement" type="src" location="local-cvs" version="1-0"/> <module name="service-spring" type="maven" location="local-subversion" development-line="BUGS"/> <module name="service-clientloader" type="src" location="local-cvs" development-line="MAIN" version="3-9"/> </modules> <include-manifest name="core-logging-4-0"/> <include-manifest name="core-utils-4-0"/> </manifest>
This manifest consists of four modules directly, but also whatever modules (recursively) consist in manifests
core-logging-4-0 and core-utils-4-0. The <module>-attributes define three
types of characteristics for the module:
name and location) define the physical location of the
module in a version control system (where, obviously, modules are stored). The name-attribute is the
technical name whereby it could be located in the version control system, but it has also a logical component by
adopting a naming scheme. This aspect will be discussed in a later section. Verder uitwerken
Build-based attributes (type) tell the Karma build-system
(Ant- and Maven-
based) how a module can be built, where to find dependencies, etc.
Software Configuration Management-based attributes (version and development-line)
define which codebase Karma should use for the module in the manifest.
The name, type and location-attributes are mandatory. The version
and development-line are optional attributes. The version-attribute combined with a
development-line-attribute means that the module version is relative to a development line. A
version-attribute alone would mean that the module version is relative to the main development line (the
MainLine>-pattern, as defined by ... Verder uitwerken).
Manifest
The <manifest>-attribute has a version-attribute. The value of this attribute identifies
which version of the manifest definition is used. It has nothing (!) to do with the version of the software component or
application that the manifest represents.
The <name>-attribute of the manifest is one of the important versioning aspects. It is an identifier
for the software component or application that it represents. Consider the following example: Oracle Corporation plans
to release a new version of its database server product. Commercially, they call their product oracle-11i, and their
release starts with version 11.1. The name of the manifest thus represents what the manifest represents.
Although an important artifact, the <name>-attribute of the manifest has no mandatory pattern it
should match. This is to allow companies to implement their own scheme. When a new major release is coming up, a company
may decide to start with a new manifest for that purpose, e.g. oracle-12i-1.0; the 'only' versioning scheme
applied on manifests is what is maintained in the version control system where manifest files are stored. But that is
not something that should be known
The software logistics process would require different types of manifests. That is, in the logical sense. We will discuss the technical implications later on in this description. When a product is planned, the development department would create a development manifest to collect all modules (and included manifests) for that product. During development, modules are changed, newer versions released and developers can optionally include.
Scenarios :
1. A separate manifest for each 'stage' in the software development cycle. component-1-0-frozen.
2. Have the process managed by Karma. Karma supports a process whereby the release manager can automatically create a
stable manifest with the create-release -t [stable|frozen]-command.
Verder uitwerken.
Thi
A modules' product life cycle starts when the module is created. The creation process is supported by Karma (the
create-module command). Karma creates the module (template-driven, whereby the template defines which
files and directories will be created) and versions the module 0-1 on the
nl.toolforge.karma.core.vc.MainLine.
The module can now be used by developers (or other interested people, why not) and included in a manifest by adding the
module definition in the manifest. The way the module is configured in the manifest defines how a developer can work
with the module in that manifest. Effectively, the initial nl.toolforge.karma.core.module.Module#State of the
module is defined by it. Applying no version-attribute nor a development-line-attribute
indicates that the module is in DYNAMIC state and that the module can be set to WORKING state
by the start-work-command to indicate that the developer
Versioning of modules is quite a different ordeal compared to versioning of manifests. Modules are maintained by Karma in the sense that Karma manages the promotion of modules (comparable to what version control systems do).
The following example shows some of the logistics involved in the promotion of a module. Suppose we have the following manifest:
Note that the developer need not know about the intricacies of the version control system that is used as a backend. For the developer (and other roles that
|
|||||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES | ||||||||||