[MCOMPILER-579] JPMS modules and --module-version (original) (raw)
Hello Maven devs,
I've hit an issue converting some Java libraries to JPMS. Guava is a popular Java library, built with Maven, and I was working on a PR to add JPMS support, but got stuck at an issue in the latest Maven version's compiler plugin:
Maven sets the module version to the project's version, which is sensible for release versions. But during development, many projects use a string version convention like HEAD-SNAPSHOT​, or 1.0-SNAPSHOT​, and these are not valid values for --module-version​.
This also appears to be unconditional behavior[1], making it very hard for modules to both ship a module descriptor and remain flexible with their versioning scheme.
For libraries like Guava, this may make JPMS support a non-starter altogether, because Google may have internal scripts and other infrastructure which rely on these string versions. Normally that would just be a problem. But with Guava being the #1 artifact in Core Utilities and #4 in terms of alltime transitive usage[2] in Maven Central, this means Guava must either:
- Stay behind on Maven 3.8.0 or earlier
- Avoid shipping a module info
- Change versioning scheme to be numeric in all circumstances
All seem to be especially poor options, particularly #2, as it would continue to impact downstream library or application authors who want to package with `jlink` et al. The transitive closure of Guava being unable to use `jlink` encompasses a vast amount of the greater Java ecosystem.
[2]: https://mvnrepository.com/artifact/com.google.guava/guava