NVO CVS Repository Structure

Schematic of proposed structure

The proposed structure tree is:

NVO/  -+-  env/
       +-  script/
       +-  distrib/
       +-  lib/
       +-  test/
       +-  contrib/
       +-  managed/  -+-  <module>  -+-  src/
                                     +-  doc/
                                     +-  distrib/
                                     +-  test/                                                                                  +-  README
                                     +-  VERSION
                                     +-  CHANGES
                                     +-  BUGS
                                     +-  TODO
                                     +-  build files

Description

• env/ and script/ contain top-level information about different platforms and for top-level builds.
• a top level distrib/ directory containing zips, jars, wars, etc. of individual modules or collections of modules
• a top level lib/ directory containing "common" libraries, e.g. axis-1.1.jar.
• a top level test/ directory containing system and module interoperability tests
• contrib/ contains third party modules, i.e. those which the NVO is not currently supporting/maintaining.
• managed/ holds the NVO software collection; each module, e.g. OpenSkyNode, has the specified structure:
  • src/ holding the source code
  • doc/ containing documentation
  • distrib/ containing releases (this will duplicate the top level in some senses)
  • test/ containing unit (module and component level) tests
  • README providing an overall description of the module
  • VERSION providing information about the current version
  • CHANGES providing a change history
  • BUGS providing a list of known/outstanding bugs in the current release
  • TODO providing a list of features to be added/wish list
  • build files for the module, i.e. how to get from src/ to distrib/.

Of course, this is just the minimal required structure and additional directories can be added, e.g. /build, at the module owner's whim.

Discussion points

• We probably need to allow for nested modules e.g. the OSQ is in CVS as SKY beneath that there is a the web site common libs and the node code.

• The top level lib/ directory could have subdirectories: common/ (holding common libraries essential to NVO modules), endorsed/ (holding approved third party libraries, such as VOPlot) and optional/ (holding the rest, e.g. saxon.jar)

• Does the proposed structure integrate with IDE's? It seems to work OK for Eclipse but what about Visual Studio? Is .NET development only going to occur in VS - what about Mono?

This leads onto the more general discussion about different languages. The suggestion is that this really ties in with responsibility for the module:

• • if one person is in charge of, say, ConeSearch and they are implementing multiple ConeSearch clients in Python, Perl and Java then the different language branches will be under src/, i.e. src/python, src/perl and src/java;
  • if a different person is responsible for each different language then there will be three different modules: ConeSearch-python, ConeSearch-perl and ConeSearch-java.

• What do we do about things like the Summer School distribution?

The suggestion is that we shoehorn this into the proposed structure and change the build scripts accordingly.

• What about XML - schemas, XSLTs, WSDLs - where do they go?

The suggestion is under src/.

• Who owns current code?

• Is Caltech looking into future replacements for CVS such as Subversion?

There does not seem to be terribly much interest in anything other than CVS by other groups in CACR but the sys admin is happy to setup something like Subversion, at least for testing, as and when.

-- MatthewGraham - 08 Feb 2005