`-jdk…` suffixes considered problematic for version and upgrade automation

[odrotbohm]

The non-standard -jdk… suffixes on some artifacts cause a bit of havoc for tools that apply standard Maven version comparisons as they consider the suffixed variant a newer version than the one without the suffix. Tools that rely on that comparison will now (suggest to) upgrade from 1.8.10 to 1.8.10-jdk5, which is unlikely what you want by default.

Sample output of a mvn versions:display-property-updates from a project that depends on 1.8.10 currently:

…
[INFO] --- versions:2.21.0:display-property-updates (default-cli) @ jmolecules-integrations ---
[INFO] 
[INFO] The following version properties are referencing the newest available version:
[INFO]   ${axon.version} .............................................. 4.13.1
[INFO] The following version property updates are available:
[INFO]   ${bytebuddy.version} ........................ 1.18.10 -> 1.18.10-jdk5
…

[raphw]

Arguably, the jdk5 version is the more universal version and if a library required jdk5 and the non-suffixed version, the jdk5 version should be picked, so in a sense Maven is right. But in the end it's up to the end user to decide if versions before JDK 8 need to be supported.

I recommend adding a Maven ruleset to exclude suffixes, or to just use the jdk5 version if jar size is not an issue. It supports anything up to modern JVMs, too.

[odrotbohm]

Aren't Maven classifiers exactly the thing you're after? See https://maven.apache.org/pom.html#dependencies

[raphw]

Unforunately, no. I thought so, but then when having Byte Buddy with and without classifier on the class path (or even worse module path), the dependency is added twice.