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 <n...@breun.nl> 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 <ta...@cservenak.net> 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 > > <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 > > > > > --------------------------------------------------------------------- > 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
