Contents of this Cougaar Release

This file documents the contents of this release and the general layout of Cougaar software modules. When you download a Cougaar release, there are several logical pieces.

BUILD ORGANIZATION

Cougaar is divided into modules, from the various cougaar.org projects that make up CougaarSE. This is a list of the various zip files available from releases.

Notes:

• You'll need cougaar.zip and cougaar-support.zip (the first time) to get a runnable system. The rest are extras. Furthermore, the cougaar-support contents do not change very often.
• The zips are designed to be unpacked in the same directory, e.g. on UNIX:

   mkdir cougaar
   cd cougaar
   unzip /tmp/cougaar.zip
   unzip /tmp/cougaar-support.zip
   setenv COUGAAR_INSTALL_PATH `pwd`
  

• The zips include version information in their respective "Manifest/" directories. The content looks something like:

   NAME=cougaar-support
   COMMENT=cougaar thirdparty jars
   REPOSITORY_TAG=V10_0 # CVS branch
   REPOSITORY_TIME=1/28/2003 13:00:08 # CVS checkout time
   ARCHIVE_TIME=1/28/2003 13:29:27 # zip time
  

  All your zips should have the same REPOSITORY_TAG and REPOSITORY_TIME. Each generated "lib/*.jar" file also contains its version information.

MODULE LIST

The Cougaar software distribution (cougaar.zip) contains a number of separate modules of related classes with supporting documentation and sources. The modules roughly correspond to separate Cougaarforge projects, though some projects contain multiple modules.

Each module typically produces a single Jar file in "lib/", as well as a directory "COUGAAR_INSTALL_PATH/" which contains data files, scripts, documentation, etc. Here is a list of those modules, in approximate order of compilation dependency or extra functionality. For detailed dependency information, see "build/data/default.build".

INTRA-MODULE ORGANIZATION

Each module subdirectory is organized in a similar way in the source repository:

 src/ integration sources
 doc/ integrations notes, etc
 data/
 configs/
 ...

PACKAGE ORGANIZATION

Software intended to replace core functionality should match the below package layout (or provide detailed arguments why it should be changed).

Software intended to augment the core and/or provide optional core functionality, but is not intended to replace the "standard" software suite, should mirror the above layout rooted in a new "organization/project/product-specific" package rather than override the core's "org.cougaar" package names. For example, an alternate implementation of the agent base class

    core/org.cougaar.core.agent.AgentImpl 

    fooco/com.foo.cougaar.palmtop.agent.EmbeddedAgent 

    "fooco/" is the module     "com.foo." is the company package prefix     "cougaar.palmtop." is the project's root     "agent" is the parallel to the core's package.     "EmbeddedAgent" is the class name