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:
com.io7m.p:io7m-p-core:1.0.0 com.io7m.p:io7m-p-documentation:1.0.0 com.io7m.p:io7m-p-tests:1.0.0
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:
com.io7m.p:com.io7m.p.core:1.0.0 com.io7m.p:com.io7m.p.documentation:1.0.0 com.io7m.p:com.io7m.p.tests:1.0.0
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.