crush depth

jregions

Have started unifying jareas and jboxes into a new project: jregions.

The original projects were written about three years apart and I'd not realized how much overlap there was between them until it was too late. This sort of code is a prime target for value types: There are four sets of specialized classes for int, long, double, and BigInteger coordinates because Java's generics don't allow for abstraction over primitive types without boxing. This is something that Brian Goetz has complained about frequently. To paraphrase, "you sometimes end up writing the same code eight times".

The jregions project is also a first attempt at moving to the OSGi conventions I mentioned previously. Thought I might as well use them for all new code and migrate the old code when JDK 9 appears.

The Question

The Question

Breaking compatibility in a patch release

Broke a pure-ftpd install this morning by recklessly failing to read the change log before upgrading. Missed this note for 1.0.44:

The Perl and Python wrappers are gone. The daemon can now use a configuration file without requiring external dependencies.

This meant that the s6 run script had to be updated:

#!/bin/sh
exec /usr/local/sbin/pure-config.pl /ftpd/pure-ftpd.conf 2>&1

Became:

#!/bin/sh
exec /usr/local/sbin/pure-ftpd /ftpd/pure-ftpd.conf 2>&1

The documentation was not updated. I had to work out how to get the server to consume the configuration file by guessing, and had to trace the executable with ktrace to make sure that it actually was reading the file.

I tend to forget that not all projects use semantic versioning and what I expected to be a simple bug-fix update from 1.0.43 to 1.0.45 turned out to be a service-disrupting change.

If you maintain software and you're reading this, please make your version numbers mean something!

pure-ftpd

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:

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

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.

No One Loves Assembly

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