-
Notifications
You must be signed in to change notification settings - Fork 24
general architecture java build
This document describes the build system as it applies to the ./clc subdirectory and all linked modules.
The focus here is the build and the organization of the code[1]Java Code Structure is intimately related
- Running top-level ./configure for:
- ./clc/eucadmin/setup.cfg.template.in
- ./clc/eucadmin/eucadmin/.py.in
- ./clc/eucadmin/bin/euca_conf.in
- ./clc/modules/postgresql/src/main/resources/postgresql-binaries.properties.in
- ./clc/modules/bootstrap/src/main/resources/version.properties.in
- ./clc/modules/bootstrap/src/main/native/arguments.ggo.in
- TODO: record why there is this back reference in each instance. Try to remove.
- Presence of top-level ./VERSION file.
- ./clc/Makefile depends on ./Makedefs
- Runtime dependency that is not enforced in build is on ./util/euca_rootwrap
- ./clc/modules/storage-controller/
- ./clc/modules/storage-common/
- ./eucadmin/
- Also, vmware-broker
- Runtime dependency that is not enforced in build is on ./util/faults
- JDK, including JNI
- ant
- ivy
- groovy
An important characteristic of the java build is that it have a simple rinse-and-repeat usage cycle.
- Compartmentalized builds to support concurrent work on multiple branches
- User-mode (no root needed) build and install (the exceptions to this are not in ./clc and don't lend precedent for it)
- Incremental: only changed modules (and their transitive dependents) require a build.
- Accurate: all changed modules are built.
- Non-volatile: can be run non-destructively against the same destination repeatedly
Dependencies between the various Eucalyptus modules in ./clc are managed using Ivy module configuration files. Using the ivy:buildlist Ant task we are able to read these configuration files and define a build order for the internal modules. Each configuration file defines the direct dependencies of a module.
TODO
When adding a new module, one will need to create an Ivy module configuration file. This file should reside in the root of the module directory and should be named ivy.xml. A typical example of the configuration file content can be seen here.
When creating a module configuration, you'll need to set the module attribute of the info tag to the name of your module (this should be the name of the module directory prefixed with eucalyptus-).
You will also need to specify dependencies using the dependency tag as shown in the example configuration file. For now, the module configuration is only used for managing inter-dependencies between Eucalyptus modules; no 3rd party modules should be specified here. The rev attribute of each dependency should always be set to the value latest.integration or it should be left off, since this is the default value.