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 <[email protected]> Sent: Tuesday, March 5, 2024 11:28:27 PM To: [email protected] <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
