Friday, April 13, 2007

OpenJUMP Package Naming Convention

A few months ago I had posted about the Java package naming convention or standard that we use in OpenJUMP. You can read that post here:

I’ve come across another “issue” with the way we name packages. I’d like to get both of these issues resolved and then decide on a consistent naming convention.

We currently have several packages in an org.openjump.core package. For compatibility reasons I’d like to change this structure so that these sub-pacakges will be found in a package named org.openjump. We can then map any package in JUMP to its corresponding package in OpenJUMP by substituting the org.openjump prefix for the com.vividsolutions prefix. OpenJUMP would still use the com.vividsolutions pacakage structure, but if new classes were added or an existing class was drastically modified it would be found in the corresponding org.openjump package. As an example of this, I created a RendererFactory class that was a new class I wanted to add to support pluggable renderers. I added this class to the org.openjump.workbench.ui.renderer package, which corresponds to the com.vividsolutions.workbench.ui.renderer package.

As a rule of thumb, if you are modifying an existing class in OpenJUMP, keep the code in the com.vividsolutions package hierarchy. If you are adding a class for OpenJUMP’s core that can’t be used outside of OpenJUMP for a practical purpose place the code in the org.openjump package hierarchy in a way that follows the com.vividsolutions package hierarchy for that Vivid Solutions uses for JUMP as closely as possible. If you need to include code for a plug-in or utility code that is maintained separately from OpenJUMP you can use your own package name.

The Sunburned Surveyor