1.  Background
2.  The Need
3.  What Is Invicta?
4.  Invicta As A Framework
5.  Technincal
6.  Basic Usage Example
7.  Future Development

1. Background

The software development world in general and the J2EE development world specifically involve various complex build related tasks.  This fact is not new.  Makefiles processed by make have been a mechanism for transferring a project's source files into a final product for many years.  However, some new software development standards of the recent years involve even more build aspects.

For example, a Java developer that wants to build and deploy a full Web Application on a J2EE application server has to do the following actions:

As can be seen in the above example, a build process is relatively complex.  It also varies from one project or developer to another (for example, no EJBs in project, automatic generation of code or descriptors, etc.).

The build process is usually performed by build scripts.  Those scripts can be simple shell scripts, standard Makefiles, or XML files of the Apache ANT tool (mainly for J2EE projects).  These tools are based on a project build process definition language.  These languages are relatively complex and require some knowledge, especially when a strong build script is required. 

The example above also shows that the actions required for building different projects are sometimes very similar to each other.  This means that many software companies and developers spend time on writing almost the same build code multiple times, instead of sharing it.

Some graphical IDE (Integrated Development Environment) applications contain tools and wizards for compiling sources and building projects.  These wizards ease the process of building a project.  However, advanced developers cannot modify the default build process.  Additionally, these features are IDE-specific, which means that performing automatic batch build processes, or sending the project to a developer that uses a different IDE or doesn't use one at all , is not possible.

Return to top

2. The Need

So, if we have Make and ANT, as well as many others, why is there need for yet another build tool?

From the above, it can be concluded what the requirements from a new build management tool would be:

Return to top

3. What Is Invicta?

Invicta is a build management tool, targeted mainly for large-scale projects. Invicta does not replace existing build tools; instead, it uses them, functioning as a stronger and easier-to-use upper layer.  This layer hides the complexity of the actual build script language and supplies additional functionalities.

While basing on Apache ANT, Invicta is not just an ANT extension; it should be generic enough to support in the future build tools other than ANT, and it is used by developers for processing their project's definition files and generating build scripts accordingly.  Each developer is able to edit very simple XML files for defining his components, their types and their relations.  These definition files become an integral part of the project, just like the project's sources.

Invicta addresses the needs of both 'simple' developers and administrator.  For developers, the basic functionality of Invicta acts as a 'black box' for building a project, as shown in the following diagram:




For administrators or advanced developers, Invicta is a framework for their complete build environment.  They can add their own customized types of components, which means writing once ANT code that can be used by all the developers in their project or company many times by simply specifying the new type name.  Invicta's extensibility also allows accessing the information processed from the project definition files for writing output files other than ANT build.xml (for example, configuration files for a specific IDE).

In order to make Invicta a useful Open-Source project that developers can easily extend and maybe contribute to its development, Invicta must be a modular extensible framework.  It should not be a 'closed' tool with a definite set of build functionalities.  It should initially have only basic build functionalities, but should define standard methods for extending these basic functionalities.  Such extensions can either be specific requirements of some developers or common functionalities that can be added to Invicta in an evolutionary way.

The following diagram shows the content of the Invicta project, the relations between its modules, the user-relevant parts and the extensible points.



The Core Engine is a Java application which processes Project Definition Files (components, dependencies, products, etc.), as well as Component Types definitions, required for the components of a specific project.  The data collected can be accessed via an API it exposes.  Output files (such as ANT build.xml files) are created by Dumpers accessing this API.

Component Types are XML definition files of build instructions for specific types (JAR, EJB, etc.). Each component defined in Project Definition Files specifies a type name that should have a matching Component Type. These are mainly templates of ANT code.  For example, JAR-Component Type definition contains the code of ANT targets for compiling Java sources and packing them into a JAR file.

Each administrator or developer that is using Invicta is able to define additional Custom Types.  These types can stand for themselves, or extend the built-in types for adding specific capabilities.

Template Handlers are how templates of Component Types access project or component-specific information.  Essentially, they are Java classes that use the API of the Core Engine for accessing the information gathered from the Project Definition Files.

Dumpers use the API of the Core Engine for creating Output Files.  As Invicta is modular, developers are able to define custom Dumpers in addition to the ones Invicta ships with:

  • ANT – generating ANT build scripts

  • Documentation – generating project documentation (Javadoc-like).

  • Project export definition – Generating a definition file of a project being distributed, to be used within a different project.

XML files of a simple structure.  Each project has its own set of files that define its components, their types, dependencies between them and various other component and project settings. These files are the input for Invicta's Core Engine, which processes them and activates Dumpers on the collected information.

Output Files are Invicta's products.  Dumpers create output files according to the information gathered from processing Project Definition Files.  The main output file is ANT build script (build.xml).

Return to top

4. Invicta As A Framework

As mentioned earlier, Invicta is not just a 'black box' taking definition files and transforming them into build instructions.  Although many of its users will only use this aspect of the product, Invicta can do much more.  As an open-source project, it is designed to be extensible by its users.  This means that within the project, standard methods are defined for extending basic functionalities.  By this, users are easily able to define the following additional modules:

Return to top

5. Technical

Invicta is developed in Java. Its framework API is also a set of Java interfaces and classes. Some standard external packages are used by Invicta's code.

The Core Engine is a Java application that was tested using Sun JDK 1.3.1 and 1.4.1.

ANT's build script generated by Invicta was tested using Apache ANT 1.5.x.

Invicta was tested both on Red-Hat Linux and Microsoft Windows.

Return to top

6. Basic Usage Example

The Weta software company starts a new project called Solenopsis.  The first version of the Solenpensis project contains four components:

Weta's administrator installs Invicta and defines a new project.  He also writes a new Custom Type named SolenopsisJAR that extends the basic JAR type for processing Weta proprietary files.

The following Project Definition File is written and maintained by Weta's developers:



<projectSettings name="solenopsis" dir="." version="1.0">

       <property name="dist.dir" value="dist/solenopsis"/> 

       <property name="local.env.dir" value="."/>

       <property name="invicta.dir" value="/home/invicta"/>



<component name="solenopsis.lib" type="Libraries">

       <product static="true" name="jakarta.commons.collections"

               file="commons-collections.jar" type="jar"/>

       <product static="true" name="jakarta.commons.lang"

               file="commons-lang.jar" type="jar"/>



<component name="solenopsis.utils" type="JAR">

       <product file="SolenopsisUtils.jar" type="jar"/>      

       <depend name="solenopsis.lib" products="jakarta.commons.lang" export="true"/>



<component name="solenopsis.core" type="SolenopsisJAR">

       <product file="SolenopsisCore.jar" type="jar"/>       

       <depend name="solenopsis.utils" export="true"/>

       <depend name="solenopsis.lib" products="jakarta.commons.collections" export="true"/>



<component name="solenopsis.ui" type="WAR">

       <product file="SolenopsisUI.jar" type="jar"/>         

       <product file="SolenopsisUI.war" type="war"/>         

       <depend name="solenopsis.core" export="true"/>




Weta's developers run Invicta on this definition file for generating an ANT build script.

Behind the scenes,  the Core Engine will process the definition file, while checking its validity.  It will also process the relevant Component Types.  It will then activate the Dumpers.  AntDumper will process the templates of the relevant types and will create an output build.xml file for the project.

Developers can now use ANT with the generated build.xml from command line or an IDE (Eclipse, for example).  Some usage examples:

Because the generated build script is strong and customizable, developers can alter the build process settings in run-time.  For example, the following command should compile solenopsis.utils with debug information:

ant solenopsis.utils.compile –Dsolenopsis.utils.compile.debug=true

Return to top

7. Future Development

Invicta is far from being complete.  There are already many suggestions and ideas for enhancement in the TODO list, among which are new Component Types, additional Dumpers and an Eclipse plug-in.  Suggestions and RFEs are welcome.

Return to top