Re: Compiler bug: Issues with JPMS module version

[Sam Gammon]

To Robert and Plamen's credit, by the way: their goal here of not being 
confusing is very admirable, but that change was made in 2018, before many 
libraries supported JPMS.

There was no feasible way to know this would be a challenge when they wrote 
that code.

The result, through no fault of their own (the underlying identifiers differ in 
definitions), is a more confusing experience, because I can't actually bail out 
of this logic if I'm using Maven. It's just that in Guava's case, Google can be 
particularly against with that sort of change, and the impact is quite large, 
given how broadly it is used.

In nearly every other case I'd just change the version and move on. Just trying 
to explain the reasoning here.

From: Sam Gammon 
Sent: Tuesday, March 5, 2024 11:40 PM
To: Maven Developers List 
Subject: Re: Compiler bug: Issues with JPMS module version

I understand that Guava specifically could change their module version, but 
what Maven is effectively enforcing here is that the project version must be a 
valid module version for all modular projects.

Maybe that’s intended, but in that case it should hopefully be documented. 
Guava surely isn’t the only project out there which has a project version that 
doesn’t start with a number.

I understand a change to the compiler plugin must be reviewed extensively, but 
the outcome that scares me is:


  *   Guava is forced to change their project version and Google chooses not 
to, for whatever reason (probably internal scripts relying on the version 
string)


  *   Or, Guava can give up Maven which is an enormous change and even harder 
to justify


  *   Or, no module which depends even transitively on Guava in the entire 
module graph can itself ship with jlink or related tools (many, maybe even 
most, libraries and apps)

So, while the project version string is arguably a fix, what if that can’t be 
changed, for whatever reason?

In this severe case, the only options are to stay back before 3.8.1, or to drop 
Maven, or to not support JPMS, which are an unfortunate set of choices to pick 
from.

Knowing this, do you see a way around this behavior without adding a kill 
switch flag? If Gradle is setting the module version optionally, why can’t 
Maven, so long as default behavior is preserved?

Some alternatives, maybe:


  *   Rejecting project versions which are not valid module versions; this 
would tie Maven’s validation logic to a moving target, the JDK, and would of 
course be a large breaking change


  *   Not providing the module version automatically at all; also a breaking 
change


  *At least documenting this requirement, which would be great but wouldn’t 
fix the underlying issue

Changes to Maven’s compiler plugin should not be taken lightly but the above 
seems to add up to a tough circumstance.

Thank you again for sharing your expertise on this matter, of course.


From: Christian Stein 
Sent: Tuesday, March 5, 2024 11:28:27 PM
To: dev@maven.apache.org 
Subject: Re: Compiler bug: Issues with JPMS module version



On 2024/03/06 07:15:11 Sam Gammon wrote:
> 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​.

That feels like the best solution to me: you opt-in to be a Java module, you 
also provide a valid (and non-confusing) Java module version. Which is in 
essence what Robert and Plamen agreed upon in 
https://issues.apache.org/jira/browse/MCOMPILER-322


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Compiler bug: Issues with JPMS module version

[Sam Gammon]

I understand that Guava specifically could change their module version, but 
what Maven is effectively enforcing here is that the project version must be a 
valid module version for all modular projects.

Maybe that’s intended, but in that case it should hopefully be documented. 
Guava surely isn’t the only project out there which has a project version that 
doesn’t start with a number.

I understand a change to the compiler plugin must be reviewed extensively, but 
the outcome that scares me is:


  *   Guava is forced to change their project version and Google chooses not 
to, for whatever reason (probably internal scripts relying on the version 
string)


  *   Or, Guava can give up Maven which is an enormous change and even harder 
to justify


  *   Or, no module which depends even transitively on Guava in the entire 
module graph can itself ship with jlink or related tools (many, maybe even 
most, libraries and apps)

So, while the project version string is arguably a fix, what if that can’t be 
changed, for whatever reason?

In this severe case, the only options are to stay back before 3.8.1, or to drop 
Maven, or to not support JPMS, which are an unfortunate set of choices to pick 
from.

Knowing this, do you see a way around this behavior without adding a kill 
switch flag? If Gradle is setting the module version optionally, why can’t 
Maven, so long as default behavior is preserved?

Some alternatives, maybe:


  *   Rejecting project versions which are not valid module versions; this 
would tie Maven’s validation logic to a moving target, the JDK, and would of 
course be a large breaking change


  *   Not providing the module version automatically at all; also a breaking 
change


  *At least documenting this requirement, which would be great but wouldn’t 
fix the underlying issue

Changes to Maven’s compiler plugin should not be taken lightly but the above 
seems to add up to a tough circumstance.

Thank you again for sharing your expertise on this matter, of course.


From: Christian Stein 
Sent: Tuesday, March 5, 2024 11:28:27 PM
To: dev@maven.apache.org 
Subject: Re: Compiler bug: Issues with JPMS module version



On 2024/03/06 07:15:11 Sam Gammon wrote:
> 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​.

That feels like the best solution to me: you opt-in to be a Java module, you 
also provide a valid (and non-confusing) Java module version. Which is in 
essence what Robert and Plamen agreed upon in 
https://issues.apache.org/jira/browse/MCOMPILER-322


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Compiler bug: Issues with JPMS module version

[Christian Stein]

On 2024/03/06 07:15:11 Sam Gammon wrote:
> 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​.

That feels like the best solution to me: you opt-in to be a Java module, you 
also provide a valid (and non-confusing) Java module version. Which is in 
essence what Robert and Plamen agreed upon in 
https://issues.apache.org/jira/browse/MCOMPILER-322
 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Compiler bug: Issues with JPMS module version

[Sam Gammon]

(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 
Sent: Tuesday, March 5, 2024 11:15 PM
To: 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 
Sent: Tuesday, March 5, 2024 11:08 PM
To: 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

Re: Compiler bug: Issues with JPMS module version

[Sam Gammon]

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 
Sent: Tuesday, March 5, 2024 11:08 PM
To: 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

Re: Compiler bug: Issues with JPMS module version

[Christian Stein]

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.
>  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