Sam Gammon created MCOMPILER-579:
------------------------------------
Summary: JPMS modules and `--module-version`
Key: MCOMPILER-579
URL: https://issues.apache.org/jira/browse/MCOMPILER-579
Project: Maven Compiler Plugin
Issue Type: Bug
Affects Versions: 3.12.0, 3.11.0, 3.10.0, 3.9.0, 3.8.1
Reporter: Sam Gammon
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 poor options especially the 2nd one, as it would continue to
impact downstream library or application authors who want to package with
`jlink` et al.
[1]:
[https://github.com/apache/maven-compiler-plugin/blob/74cfc72acae4f55708bca189b2170167e83df6b3/src/main/java/org/apache/maven/plugin/compiler/CompilerMojo.java#L304-L305]
[2]:
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
