Build System Ideas -- Rough Draft

• Kepler consists of n semi-autonomous modules including the "core" module (R1)
• A build can consist of one or more modules built together (R1, R7)
• Modules can depend on each other and other externally retrievable jars/modules (R1, R12)

Explanations

• Main Build System
• Checks and retrieves module dependencies (R1, R12)
• Performs basic compilation of modules (R1, R17)
• allow individual modules to perform module-specific build activities (i.e. a callback) (R7)
• Performs packaging (jarring) of compiled code
• Allows source to be included or excluded from individual modules (for IDE/debugging/distribution purposes)
• Creates installer for a given build (R14)
• Creates developer documentation (javadoc) (R15)
• Makes it possible to run regression tests on modules (R16)
• Modules
• Define dependencies required for compilation/runtime (R5)
• Can build independently from main build system (R1)
• Can include callback so that main build can perform module-specific tasks (R1)
• Core (module)
• The Kepler "core" is just another module
• Many other modules will depend on it
• Limited system level functionality that does not include a GUI (GUI would be its own module)
• Actors
• Each actor is its own module
• It can depend on other modules or jar files
• It can be built alone based on its dependencies (note that an actor will probably always depend on one or more Kepler or Ptolemy modules due to the class it extends or interface(s) it implements)
• SVN version number *could* be used as actor LSID object number so that we know LSIDs within the kepler-project.org scope are unique.  The version would automatically be updated whenever the actor is committed.  Might need to figure out a way to do minor edits without changing version number or allow the author to update either the object number or the revision number in the LSID.
• Even though this breaks up the modules with a high degree of granularity, it makes other features such as actor groups and automatic actor versioning possible.  It also allows actors to be developed independently from the rest of the actor base (and even parts of Kepler that the particular actor does not need).  
• Actor Groups
• Actors can be built or distributed in groups
• An ActorGroup module would define the actors (modules) that it requires
• A group should be able to define how its members appear in the actor library
• Groups of groups are possible, e.g. the entire actor library could be a group of groups with its own domain specific ontology for organization within the Kepler application
• A group could be built and distributed separately from Kepler (via the actor repository or kar file)