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