1. Guidelines
2. Components And Types
3. Definition Files
4. Project Relations
5. Framework (Customization)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:
Hiding build complexity - make the creation of a complex ANT build script almost magical in terms of simplicity to the developer. Do not make him study a new script language.
Strictly defining a project's structure (componentization) - if it's done while developing the project, why not do it while designing its build? Enforcing this object-oriented methodology according to which most developers work is bound to have advantages in many aspects (familiarity, code clarity, etc.).
Having a powerful build script that can be reused for many projects with minor adjustments - has anyone mentioned "code replication"?
IDE independence - when the user codes an application, he is not limited by the IDE; there is no reason to limit him when developing the build process by binding him to a specific wizard or definition tool.
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.
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.
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.
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.