[
https://issues.apache.org/jira/browse/MCOMPILER-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17924154#comment-17924154
]
Slawomir Jaranowski commented on MCOMPILER-579:
-----------------------------------------------
Mentioned issue MCOMPILER-446 was closed without fix with conclusion:
{quote}
the maven-compiler-plugin should always use --module-version based on the
project version.
{quote}
> 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, 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.
>
> [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)
