[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ohf-dev] Coding Standards 
Hi Dan

lot's of tough questions here.

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?

yes and no. there's a triple structure, folders, plug-ins and then class namespacs
within the plug-in. We could choose to pursue completely different policies between
plug-ins and class namespaces, but I think we should pursue the same policy. or
at least a coherent policy. the outer folders group the code/plug-in packages by component, let us organise things.

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


The interface has it's own project? ok

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.

well, we don't need to change it. But in principle, in order to carry code in the namspace org.hl7.x, we need to be sure that it's right for us to do so, that we have the proper relationships with HL7, and also that there's not going to be a clash with some other party who might rightly claim that they have as much right to use org.hl7.x as us.

I think that the relationship stuff is ok, we've got that covered.
As for the names, my personal opinion is that, particularly with the interface code, we would be justified to use org.hl7.cts
though I'd rather have .cts.mapi rather than .ctsmapi. But I understand that you already have lot's of code, and Harold and Chris will have opinions etc. I just think that the org.hl7 namespace is already corrupted by careless policy on the part of the javaSIG, and we should be careful.

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.

well, the correct Eclipse answer to this is that you should use the plug-in
extension framework to cleanly divide between the 2. But that's no answer
for the CTS (yet?). Another possibility is to use org.eclipse.ohf.cts internally. As you and Russ control this namespace, there won't be any
surprises there. I'd prefer the org.eclipse.ohf root, but again, there's
lot's to consider.

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. 

don't understand - are you saying that the ohf package structure is not
good for you internally?

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

ok. maybe. I understand that, but is that a reason why they shouldn't extend OHFException instead of whatever they do extend?

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.

lovely. How do you guys manage locating this data during the JUnit tests? We have the same issue, and we haven't found a happy answer yet.

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

about the kind of challenge I expected CTS to throw up so far ;-)

Grahame