The Hackystat Build System is designed to support the following types of users and usages:
Hackystat administrators. The system should be simple for Hackystat administrators to use for installation of Hackystat servers without detailed knowledge of Hackystat internals.
"Internal" Hackystat developers. The system should facilitate developers in debugging and enhancing Hackystat. "Internal" Hackystat developers are those who work on the set of public modules published by the Collaborative Software Development Laboratory at the University of Hawaii. These developers generally have full commit privileges to the Hackystat source code repository.
"External" Hackystat developers. "External" developers are those outside of CSDL who wish to augment Hackystat with extensions specific to their development context. They may not have commit access to the Hackystat source code repository, but they require a way to integrate their extensions with the public distribution.
Developers of Hackystat configurations. The system must support the design, implementation, debugging, and enhancement of Hackystat configurations: subsets of Hackystat modules focused on particular kinds of tasks (project prediction, or software engineering coursework) or domains (high performance computing, agile development).
Automated build agents. The Hackystat Project employs CruiseControl to automatically build and test all public Hackystat configurations once a day. The build system must support completely automated checkout of sources, compilation, building, testing, and report generation.
In response to these needs, the Hackystat Build system is designed itself in a modular, extensible fashion. There are three basic components:
The module-independent build system. There are approximately two dozen Ant build files in the hackyCore_Build directory (*.build.xml) which provide the core functionality for the Hackystat build system. These targets do not reference any specific Hackystat modules.
The module-specific build files. Each Hackystat module must contain a file called "local.build.xml", which contains targets that implement the code necessary to build and test this module as part of a Hackystat configuration. Each local.build.xml file must provide a set of required targets that must be named and implemented according to specific conventions in order to integrate correctly with the build system.
The AutoConfig task. When a developer wants to create a functional build system from sources, they must first invoke 'ant -f autoconfig.build.xml'. This executes a task that inspects all of the sibling directories of hackyCore_Build for their local.build.xml files, and uses this information to create a file called modules.build.xml in hackyCore_Build. The modules.build.xml file provides a set of targets that effectively "glues together" the module-dependent targets in the various local.build.xml files to the module-independent build system in hackyCore_Build. AutoConfig need only be run whenever the set of modules in the system changes or the local.build.xml files are updated. AutoConfig also generates a file called sample.hackystat.build.xml, which can be used as a template for your local hackystat.build.xml file.