Table of Contents
Abstract
This chapter describes the general organization of the source code in any sister project, and provides general guidance on how to build sister projects from source. Follow the steps in this chapter if you want to build the sister projects from source, or want to contribute back to the sister projects.
So far as possible, the codebase for each sister project follows the same basic directory structure, though the modules in each and their implementation will vary of course. The instructions given here are general a guide, but you should also consult the developers' guides for each sister project for any additional details, and any artifacts that fall outside the standard directory structure. (For example, the Star Objects project itself supplies the corporate POM and a site template, the steps for which documented in Part IV, “Building and Deploying the Corporate Artifacts” of part three of this guide.)
Although the code in every sister project is different, they all (try to) follow the same general hierarchy:
trunk/
main/ # main module, aggregates submodules
pom.xml
applib/ # application library (if any)
documentation/ # users' and developers' guides
xxx/ #
yyy/ # modules specific to the sister project
zzz/ #
support/ # optional, built after main
pom.xml
release/ # a consistent stack of dependencies for this release
archetype/ # quick-start archetype (if any)
testapp/ # optional, not released
pom.xmlThe main module is a parent that aggregates the various submodules that make up the sister project:
the applib (if any) contains the application library. For example, Restful Objects defines an applib for client-side applications calling the RESTful web service;
the documentation, holding users' and developers' guides;
any further submodules that make up the application. For example, Restful Objects has a viewer module; JPA Objects has a module for an object store implementation.
The steps for building the main module for most sister projects will amount to little more than:
cd trunk/main mvn clean install
If you want to build a single module, then use the '-pl' flag. For example:
cd trunk/main mvn clean install -pl documentation
just builds the documentation.
Alternatively, in general it's also possible to cd into the appropriate directory and build from there:
cd trunk/main/documentation mvn clean install
The support module, if it exists, is another parent that is built after the main module. It aggregates submodules that to help developers use the sister project:
a release artifact, which defines (in
<dependencyManagement>) a consistent
set of artifacts. This can be used as a parent (or at least
documents the set of dependencies that have been tested
together);
an archetype artifact, which can be used for quick-starts. The archetype should be designed to work with the Naked Objects "claims" example. In general the modules created by running the archetype should use the release artifact.
The steps for building the support module for most sister projects will again amount to little more than:
cd trunk/main mvn clean install
The reason that the support module is built after the main module is because it requires the main's submodules to be have released.