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
