[
https://issues.apache.org/jira/browse/MCOMPILER-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Gammon updated MCOMPILER-579:
---------------------------------
Description:
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 especially the #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.
[1]:
[https://github.com/apache/maven-compiler-plugin/blob/74cfc72acae4f55708bca189b2170167e83df6b3/src/main/java/org/apache/maven/plugin/compiler/CompilerMojo.java#L304-L305]
[2]: https://mvnrepository.com/artifact/com.google.guava/guava
was:
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 especially the #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.
[1]:
[https://github.com/apache/maven-compiler-plugin/blob/74cfc72acae4f55708bca189b2170167e83df6b3/src/main/java/org/apache/maven/plugin/compiler/CompilerMojo.java#L304-L305]
[2]:
> 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.8.1, 3.9.0, 3.10.0, 3.11.0, 3.12.0
> Reporter: Sam Gammon
> Priority: Major
>
> 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 especially the #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.
>
> [1]:
> [https://github.com/apache/maven-compiler-plugin/blob/74cfc72acae4f55708bca189b2170167e83df6b3/src/main/java/org/apache/maven/plugin/compiler/CompilerMojo.java#L304-L305]
> [2]: https://mvnrepository.com/artifact/com.google.guava/guava
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
