[kepler-dev] CVS layout and branding

[Christopher Hylands Brooks]

There are many different ways to handle Ptolemy/Kepler source code
management issues.

There is another project here at Berkeley called Mescal
that faces similar issues.

Currently, there is a ptII CVS repository and a mescal
cvs repository that gets checked out within the ptII CVS repository:

  cvs co ptII
  cd ptII
  cvs co mescal

When we ship mescal, we remove the unused parts of ptolemy and
rename the top level directory so that the tar file that is shipped
starts with mescal-1.0/

The Ptolemy II infrastructure includes a configure script, support for
make and Eclipse, support for branding and managing copyrights.

The branding facility means that the user runs a binary
called 'kepler', which brings up a Kepler specific splash screen
with Kepler specific menus etc.

The copyright management scheme is a bit of a hack where if
the user goes to a URL (about:copyright), then we look for
specific class files that are present in the runtime environment
and include links to the appropriate copyrights.

I propose that we do something similar for kepler, where there
is a separate kepler repository that resides inside the ptII
respository.  When we ship releases, we brand the release so
that it looks like Kepler, not Ptolemy II.

An alternative would be for kepler to have its own build
system etc and to use Ptolemy II jar files.  The Ptolemy
II tree could be modified to build a ptkepler.jar file
that would contain what is necessary to run Kepler.

I'd rather go with using the Ptolemy II infrastructure, but if someone
wants to maintain the alternative infrastructure, then that would
work.  

I think that to start, it would be better to go with having
a separate kepler repository inside the ptII tree.



BTW - Setting up a configuration for Kepler is fairly straightforward.

With Mescal what we did was create ptII/mescal/configs/mescal/
and then create a custom MescalApplication class that is a fairly
small class that extends VergilApplication.  This has the advantage
that Mescal developers can modify the configuration as they see fit
and they do not need to modify the Ptolemy sources.

An alternative is to put the Kepler configuration into the Ptolemy
tree (as ptolemy/configs/kepler), but this means that Kepler
developers would need to modify the Ptolemy sources.

If we followed the Mescal model, then we would create
KeplerApplication and kepler/configs/kepler/
We could also modify bin/ptinvoke so that one could invoke
A script named 'kepler'

-Christopher