Re: Maven Version Order Spec: Implicit Initial Separator and Trimming

Howdy,

yup, you got to the correct conclusion.

Still, let me explain a few things:
- Version, VersionScheme interfaces are public, you don't want to go
directly for Generic* classes!
- Version instance is _only_ about ordering, is not a generic version "parser"
- GenericVersion is created by GenericVersionScheme exclusively.
- is not, in fact, it is reusable, see for example here
https://github.com/maveniverse/toolbox/blob/6442611992f83a85de5235616c38c05cb180ec8e/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/ToolboxCommando.java#L411

And a general note: even if your shop decides on semver, Maven as tool
must handle much broader (and weirder) versions, as even if your
projects are semver versioned, your transitive or
transitive-transirtive deps may not be. Hence, maven Version is
_generic_ as it must handle _all versions out there_.

Also, Version.toString will return "original" String it was parsed from:

String version = "1.0.0"
Version v = new GenericVersionScheme().parseVersion(version);
assertEquals(version, v.toString()) // Version.toString will give back
"original" parsed string.

That said, as Version is just "generic holder", one can still play
semver and other nice things:
https://github.com/maveniverse/toolbox/blob/6442611992f83a85de5235616c38c05cb180ec8e/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/ArtifactVersionSelector.java#L93
etc

On Thu, Aug 14, 2025 at 2:58 PM Nils Breunese <[email protected]> wrote:
>
> We have some code that uses the ArtifactVersion interface and DefaultArtifactVersion implementation from maven-artifact 3.9.11. Reading this thread makes me think I should be looking into migrating away from this dependency.
>
> I just took a look at maven-resolver-util to see if I could migrate this code, but org.eclipse.aether.version.Version (from maven-resolver-api) only has a toString() method (much more bare bones than org.apache.maven.artifact.versioning.ArtifactVersion), and the org.eclipse.aether.util.version.GenericVersion implementation (from maven-resolver-util) is package private, so I can’t reuse that in my application.
>
> Is it intentional that it’s not possible to reuse Maven's version implementation in your own application?
>
> I guess we could also consider migrating to another library, like semver4j, because we also need the concept of major/minor/patch versions, which doesn’t seem to be present in maven-resolver-util’s Version interface anyway.
>
> Nils.
>
> > Op 11 aug 2025, om 22:08 heeft Tamás Cservenák <[email protected]> het volgende geschreven:
> >
> > 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
> > <[email protected]> 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 <[email protected]>
> >> 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
> >>> [email protected]
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [email protected]
> >>> For additional commands, e-mail: [email protected]
> >>>
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>