crush depth

Java Module Renaming

Right now, all io7m modules are consistently named. For version 1.0.0 of a given project p, the project usually has artifacts with coordinates such as the following:


I follow the Maven conventions with the addition of an io7m- prefix on artifact names. This helps ensure uniqueness with respect to other Java projects when considering artifact names in isolation; people who aren't me are relatively unlikely to prefix their project names with io7m-.

However, the conventions used for OSGi projects typically look something like:


Examples on Maven Central

I suspect that this naming convention is rooted in the way that OSGi implementations typically deploy bundles: Bundles are placed into a single directory which is polled frequently by the container, with new bundles being automatically deployed. With the old Maven convention, the artifact names can come into conflict when placed in a single directory:

com.acme.math:math:1.0.0    -> math-1.0.0.jar
org.example.math:math:1.0.0 -> math-1.0.0.jar

With the OSGi naming conventions, this would not occur:

com.acme.math:com.acme.math:1.0.0       -> com.acme.math-1.0.0.jar
org.example.math:org.example.math:1.0.0 -> org.example.math-1.0.0.jar

As I move all of my projects over to OSGi, I suspect that I'm going to make sweeping major-version-incrementing changes to all projects by changing their names to use the OSGi naming conventions. Personally, I find it more aesthetically pleasing anyway.

There is the possibility that changing the entire name of a project could be considered a non-compatibility-breaking change according to semantic versioning: If I change the name of the project, I can't be breaking anyone's code because there could be no code in existence that has been compiled against the new name. In order to signal a clean break, however, I'm going to treat it as one and increment the major version numbers everywhere. One minor issue is that JDK 9 is due out in a few months and when that happens, I'm going to move all projects to using Java 9 as a minimum requirement. That is, they're going to require JDK 9 to build and all produced artifacts will be Java 9 bytecode. This is without a doubt a compatibility-breaking change. It may be better to wait until JDK 9 is out and then do the project renames, module descriptors, and the bytecode version increment all in one go.