Re: [ohf-dev] Coding Standards

[Dan Armbrust <daniel.armbrust.list@xxxxxxxxx>]

A few clarifications, a few questions...

Are we making a distinction between the layout of folders in the CVS 
repository and the package structure that we use in the java packages?

Let me try give a clear description of the hierarchy that we currently 
have, so we are all starting from the same page.

LexGrid is our standard data model that the LexGrid Editor and CTS use 
for data storage.

If I was going to organize our current packages according to how they 
tie together, it would look something like this (each item that has a 
'*' in it is a different project that would have its own src tree, etc):

LexGrid
	CTS
		* CTS Interface
		* CTS Implementation
		* CTS GUI Demo Tool
	* LexGrid Editor
	* LexGrid Converter


Now, as far as the actual java package structure - the CTS interface 
currently has the following structure:
org.hl7.CTSVAPI...
org.hl7.CTSMAPI..
org.hl7....

And I don't think that we want to change that.  I'd need to talk to 
Harold about it at a minimum.

Our implementation currently has the following structure:

edu.mayo.informatics.cts....

I could be convinced to change it to a org.eclipse.ohf structure, but it 
will cause more of a dual maintenance headache, since its possible I 
will have internal development here that would then need to be pushed 
out to OHF at some point.

I won't speak to the LexGrid Editor (Russ gets to deal with that)

The LexGrid Converter (which is used for loading data of various formats 
into the formats that CTS and the LexGrid Editor require) currently has 
the following structure:

edu.mayo.informatics.lexgrid.convert

And I have little interest in changing that - The converter is still 
under heavy development, and will stay that way for quite some time.  I 
  think that we have to maintain our internal copy of this code.  If it 
has to be changed to an ohf package structure before it can be released, 
then what we provide is more likely to be an occasional drop, rather 
that incremental commits of bug fixes and enhancements.

Exceptions:
Exceptions for CTS are part of the CTS Specification, so they wouldn't 
change.

I wouldn't consider it practical to change the exceptions in the LexGrid 
Converter for the same dual maintenance issues noted above.


Other bits of info:

The JUnit tests that ship with CTS also come along with sample data 
sets.  The JUnit test actually uses the converter to load the data that 
is required into a hypersonic DB, and runs the tests against that 
database.  It can be configured to run the tests against the other 
supported databases as well (MySQL, PostgreSQL, DB2, Oracle, MS Access). 
 So all of the necessary data would be part of the CVS repository.

JVM Versions:
Creating the CTS interfaces required JDK 1.4.
Running CTS only requires JDK 1.3
The LexGrid Converter should be fine with 1.3 (but I haven't tested in a 
while)


So, how does all of this information (not) fit with the world?

Dan







--
****************************
Daniel Armbrust
Biomedical Informatics
Mayo Clinic Rochester
daniel.armbrust(at)mayo.edu
http://informatics.mayo.edu/