Invicta Concepts

1. Guidelines
2. Components And Types
3. Definition Files
4. Project Relations
5. Framework (Customization)

1. Guidelines

As stated elsewhere, a traditional build process has quite a few problems.  Invicta was conceived in an attempt to solve many of them.  The following ideas functioned as guidelines when designing Invicta:

Return to top

2. Components And Types 

Componentization is a key concept in Invicta.  Each project is divided into a set of Components, which maintain dependency relations between them.  Each component has a Type, which is best thought of as a class.  Essentially, the Type defines a build script template which will be used for this component.  The components themselves are built separately.

The similarity to object-oriented methodology  is not a coincidence; the terms Type-class and Component-instance are interchangeable.  This makes Invicta's ability to define a hierarchy of Types only natural.  For example, an EJB Type extends the JAR Type, being a special case of it.  Similarly, all Components of the same Type share the same structure (directory, files, naming, etc.).

More material regarding Invicta's Types can be found in Built-in Types, in the Basic Usage manual.

Return to top

3. Definition Files

An Invicta project bases on Definition Files, which are simple, self-explanatory and easy to edit XML files.  The files may be maintained by an Administrator, a Build Manager, or by any developer.  Inside these files reside the definition of the project's settings, components, dependencies between components, products and properties.

The Project Definition Files are most of the work the "build developer" has to invest in the Invicta project (see the Framework section for information regarding advanced extensibility options of Invicta).  In a sense, they "represent" the project, since all the information needed for the dumping (or creation of the output) can be gathered from them.  Once written, they become a part of the development project's sources, and as such should reside in a code repository system.

To learn more about using Project Definition Files, click here.

Return to top

4. Project Relations

A common problem in the build management world is the existence of a project that depends on another project in order to be built correctly.  Invicta solves this issue in an elegant way.  One of the available products of the dumping process is a project definitions export file, built according to a strict distribution structure.  The file contains a single Component, with a Product for each of the products of the project's components.  In the dependent project, this file is used as one of its Definition Files, seamlessly integrating with other internal project files.  This way, the dependent project is familiar with the output of the project it is dependent upon automatically, with no extra work to the developer.

To learn more about exporting a project in order to use it in another one, read the Inter-project relations section in the Basic Usage manual.

Return to top

5. Framework (Customization)

As mentioned in the overview, Invicta can do much more than remain confined to its built-in features.  With little effort, a developer can extend Invicta to comply with the requirements of a specific project, by implementing the appropriate interface.  So whether you want to define a new Template Handler, create a Type for EJB files, or have Invicta's output be a graphic representation of the relations between components, you can achieve it easily.

Learn how to define new Types, Template Handlers and Dumpers.

Return to top