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 <sam@less.build> Sent: Tuesday, March 5, 2024 11:40 PM To: Maven Developers List <dev@maven.apache.org> 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 <s...@apache.org> Sent: Tuesday, March 5, 2024 11:28:27 PM To: dev@maven.apache.org <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
