(Sorry, forgot to say; the reasoning for a killswitch flag: ultimately, a Maven user can just provide --module-version via compiler arguments so long as Maven isn't injecting it.) ________________________________ From: Sam Gammon <sam@less.build> Sent: Tuesday, March 5, 2024 11:15 PM To: dev@maven.apache.org <dev@maven.apache.org> Subject: Re: Compiler bug: Issues with JPMS module version
Hey Christian, I hadn't noticed that test, thank you. That's very helpful, maybe, then, Guava's string HEAD-jar-SNAPSHOT can simply be a change to 1.0-HEAD-jar-SNAPSHOT. Still, though, I can't help but wonder if this should be made configurable, if even to withhold the argument (the default behavior is sensible) to allow an escape hatch in case the module version should differ from the project's version. As for what other builders do: * Gradle only sets the module version<https://github.com/gradle/gradle/blob/59bc291014234328b0a397d40fb45d6f2c4b2737/platforms/jvm/language-java/src/main/java/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilder.java#L284-L287> if explicitly set in the Java compiler options * Bazel does not appear to support JPMS at all<https://github.com/bazelbuild/rules_java/issues/136> (at least out of the box) So I suppose there is not much consensus to look to... Once I get a committer email set up I will propose a PR which adds the guard lines, and potentially an option to killswitch the module version, so long as people are up for it. What do you think? I am definitely open to feedback and thank you for your help on this. Sam ________________________________ From: Christian Stein <s...@apache.org> Sent: Tuesday, March 5, 2024 11:08 PM To: dev@maven.apache.org <dev@maven.apache.org> Subject: Re: Compiler bug: Issues with JPMS module version The commit you linked contains a test for "1.0-SNAPSHOT", a valid version string according to Java's module descriptor version schema as defined here: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/module/ModuleDescriptor.Version.html "HEAD-SNAPSHOT" fails due to it doesn't start with a number. Maybe a check via ModuleDescriptor.Version::parse(String v) should guard the lines you linked. Cheers, Christian On 2024/03/06 06:46:27 Sam Gammon wrote: > Hello Maven devs, > > Longtime user, first time mailing list subscriber. > > I was attempting to convert some Java libraries to JPMS modules today, and > ran into a compiler issue with Maven version 3.8.1 and above; this deals with > the --module-version flag. > > 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. > > To make matters worse, it appears this behavior is > unconditional<https://github.com/apache/maven-compiler-plugin/blob/74cfc72acae4f55708bca189b2170167e83df6b3/src/main/java/org/apache/maven/plugin/compiler/CompilerMojo.java#L304-L305>. > For now, I've resorted to building a JPMS module in another project, or > making it available in a pre-built JAR, and then merging it in at the last > minute, so that Maven is effectively unaware of it. This is not ideal though > and I can't possibly see how this scheme could work in the presence of string > versions which are quite popular. > > Is there a way to circumvent this behavior that I'm not seeing? Has anyone > else run into this issue? > > FWIW, the library I am converting at the moment is Guava. While the direct > impact of this bug (if indeed it is a bug) is small, the indirect impact may > be quite large in terms of holding the JPMS ecosystem back. If there are > libraries out there that can't ship a module-info.java because of a version > alignment/build issue, it would explain maybe why so few libraries ship with > module descriptors. > > I would be happy to propose a PR on GitHub with a fix, but I wanted to ask > first and request access to file a formal bug / give time for discussion. > > > Cheers and thank you everyone here for your hard work on Maven, > Sam > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
