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.
Deeply unimpressed by the complete lack of response to a report of a fairly serious bug in the Maven Assembly plugin. Polite requests for assistance on the developer mailing list went ignored. Hopefully this is just down to everyone being busy with the 3.5.0 release and not indicative of the Assembly plugin basically being abandonware.
Right now, if you want to create a distribution archive when using version ranges to refer to artifacts within the current reactor, you're basically out of luck.
2017-02-28: The title of this post has been modified in order to protect the pedantic.
2017-06-17: This turned out to be my fault. See: Assembly Redux
Huge respect for the LWJGL project with one of the best responses to a bug report I've ever had the pleasure to be involved with.
As a result, I'm now maintaining OSGi bundles for LWJGL. I also have working OSGi bundles for JogAmp but the JogAmp projects appear to be on life support at best.
Been experimenting with independent module versioning by developing an OSGi IRC bot. The idea is to expose any deficiencies in tools when modules within a single Maven project have different version numbers.
Initial indications are good!
One serious issue is that with independent versions, sooner or later there's going to be a release of the project where one or more modules haven't been updated and will therefore have the same version numbers as existing already-deployed modules. It's therefore going to be necessary to work out how to prevent Maven deploying bundles that already exist. Apparently, Charles Honton has a plugin for this.
Conceptually, moving to independently versioned modules means that a given project version now describes a set of module versions as opposed to simply defining a single version for all modules. I might rewrite changelog to better fit with this fundamental conceptual change.
