[
https://issues.apache.org/jira/browse/MCOMPILER-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17926426#comment-17926426
]
ASF GitHub Bot commented on MCOMPILER-579:
------------------------------------------
mguillem commented on PR #273:
URL:
https://github.com/apache/maven-compiler-plugin/pull/273#issuecomment-2654032367
@slachiewicz the changes have been picked up from master branch. The master
branch contains unit tests for that but the setup for these tests is not
available in the 3.x branch and would be far more complex than the 3 trivial
lines of code changed in this PR. Backporting the tests make only sense to me
if I can be sure that there is an interest for them from the project
maintainers.
> 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)
