APT Package Structure

When trying to decide how to package up the various pieces of APT
software, and other STScI Java software, I have always come to a
problem when it comes to deciding exactly what the package structure
should be.  The following is a philosophy statement about Java
Packages at STScI, in the hope that it will help determine what
packages should be offered.

Packages are groups of tightly related code files.  For a particular
application or project, they represent the core code framework
required to instantiate that project.  Packages relate domain
information about who is doing the work, project information, and
context information.  All of this needs to be taken into account when
developing a package hierarchy for a set of Java classes.

One key element is that packages should be shallow.  The Package
hierarchy need not follow the extension hierarchy of the classes that
are implemented.  For example, if Foo1 extends Foo.  And Foo is in
package bar, Foo1 can still be in bar, in bar.subbar, or in baz.  It
all depends more on how Foo1 will be used and not on its relationship
to Foo.

For APT projects, I propose that the following philosophy be applied
to our Java classes.

   1) Everything uses the common domain edu.stsci
   2) Generic tool code goes in its own package at the next level
   3) HST specific code goes in edu.stsci.hst, with sub-packages
      for each tool which has HST specific code
   4) Code for other observatories or missions get their own
      packages, with tool specific sub-packages

For the APT Framework, we will be using the following APT Package
structure.

+-edu
  +-stsci
    +-apt
    | +-controller
    | +-model
    | +-view
    +-hst
    | +-apt
    |   +-controller
    |	+-model
    +-util

The OCM should also be reconfigured to fit into this hierarchy:

+-edu
  +-stsci
    +-apt
    | +-controller
    | +-model
    | +-view
    +-hst
    | +-apt
    |   +-controller
    |	+-model
    | +-ocm
    |   +-test
    +-ocm
    +-util

It is unclear whether we should make any attempt to repackage existing
code, but at least now there is a philosophy by which we can properly
package future code.


-Rob Douglas