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
