Just a heads up: maven-artifact is dead (legacy); the exact reason why it is stopped being supported is that since 2010 there is duplicate (and superior) implementation for versions in Resolver. Also note that maven-artifact is deprecated in Maven 4.
That said, the "effort worth" implementation is in maven-resolver-util. Not comprehensive, but ran some examples for this thread: https://gist.github.com/cstamas/72e5072f11ab4c82c0138517f73e17e1 The spec are here: https://github.com/apache/maven-resolver/blob/maven-resolver-2.0.10/maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java Thanks T On Mon, Aug 11, 2025 at 9:35 PM Ron Desmond <rhdesm...@google.com.invalid> wrote: > > Thanks all, I agree unit tests would be helpful for understanding the > intended behavior. > > Secondly, I adjusted my "reply-to" in my gmail settings; hopefully this > resolves the reply-to issue. > > Lastly, there are two regrettably lengthy follow-ups below that relate to > handling versions like "-1" (hyphen as initial token); if these are > clarified I can take a stab at some PRs for both the spec and > maven-artifact code to close this out. > > ---- > Trimming "---1" > > Trimming and tokenization are substantial sections of the version spec and > factor into the version comparison logic depending on their semantics, so > I'm not sure they can be disregarded when considering the spec. > > The sentence <https://maven.apache.org/pom.html#Version_Order_Specification> > "this process is repeated at each remaining hyphen from end to start" > implies that "---1" and "-1" should be equivalent. Is this understanding > correct? > > ---- > Versions that Start with Hyphen > > > I'm still unsure of the correct behavior w/r/t the spec when the initial > character is a hyphen. Some ideas I had: > > (1) is not trimming the initial null value. Then versions with an initial > hyphen would have a "0-" prefix when performing comparison (` Empty tokens > are replaced with "0" `). If the padding understanding is incorrect please > let me know. This leads to the potentially unintuitive result that "alpha" > < "-alpha" instead of "alpha" = "-alpha" > > Examples: > > "-foo" -> "0-foo" > "-123" -> "0-123" > > Example comparisons of interest: > > "foo" < "-foo" // "foo" < "0" because nonnumeric qualifiers are > less than numeric qualifiers > "alpha" < "-alpha" // "alpha" < "0" similar to above except special > qualifiers are less than numeric qualifiers > > > (2) is treating versions as having an initial number. Intuitively, an > initial numeric token (that's not trimmed) would make the most sense > because versions are generally numeric in nature. If the initial token is > not a number, the initial numeric token would be 0. You don't say "this is > version alpha" without understanding that this would be the initial alpha > release, e.g. "0-alpha". > > Sure, there may be software projects that use solely nun-numeric versioning > schemes like the greek alphabet; in which case "alpha" may refer to the one > and only "alpha" release, but this would be the exception (the "odd duck", > bless that developer) and hopefully not the rule. > > Examples for the initial number proposal: > > foo -> 0-foo // transition between numbers and characters is > equivalent to "-", "-foo" = "foo" > .alpha -> 0.alpha > -1 -> 0-1 // 0 value not trimmed > > (3) is trimming the initial null values that don't have a separator. In > this case, the three versions would be equivalent: "--1" = "-1" = "1". > This is a bit unintuitive, since "-1" implies some sort of prerelease or > revision of the "0" version as noted in idea (1). > > ---- > > Hope this makes sense, thanks again for the time. > > Best, > Ron > > On Sat, Aug 9, 2025 at 9:16 AM Elliotte Rusty Harold <elh...@ibiblio.org> > wrote: > > > > So to recap, had three questions: > > > > > > 1) should versions be treated as if there's an implicit separator? > > > 2) how should trimming/tokenization work for "--1--" and "--1-"? > > > 3) how should trimming/tokenization work for "abc" and "-abc"? > > > > > > Trimming and tokenization are implementation details and are not > > guaranteed. What's guaranteed is how version strings compare to each > > other. If you ask how two specific version strings compare to each > > other, then the spec should answer your question. If it doesn't, > > that's a spec bug. > > > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
