Howdy, This is on purpose.
VersionResult is "version resolution", that in case of input: * release version (ie. "1.0") is really a no-op (you get same value back) * snapshot version (ie. "1.0-SNAPSHOT") is operation involving metadata (and you get back timestamped snapshot) * etc And, _usually_ after version resolution you immediately go to artifact resolution, where you construct an Artifact using G:A:resolvedVersion, and DefaultArtifact accepts Strings for all three parameters. On the other hand, VersionRangeResolution is a totally different beast: it's API _promises_ "ordered version list", and as you know, the only reason for Version is ordering (is Comparable). Moreover, that ordered list is post processed, see VersionFilter, and there is one Version picked up from the ordered list of Versions. But to order them, you do need Version and not String. Basically that is all: to prevent String -> parsing into Version -> only to invoke version.toString in DefaultArtifact ctor. HTH T On Thu, Aug 15, 2024 at 7:24 PM Konrad Windszus <k...@apache.org> wrote: > Hi, > I am wondering why org.eclipse.aether.resolution.VersionResult[1] uses the > type String for the resolved version while > org.eclipse.aether.resolution.VersionRangeResult[2] uses type > org.eclipse.aether.version.Version. > This doesn’t seem very consistent. Is there a reason why it is not parsed > for the former? I know parsing is necessary for the latter to ensure > correct ordering. > > Thanks for some pointers, > Konrad > > [1] - > https://github.com/apache/maven-resolver/blob/362a43675f01b8bb3d85d7b0ff76a21d57de6fee/maven-resolver-api/src/main/java/org/eclipse/aether/resolution/VersionResult.java#L94 > [2] - > https://github.com/apache/maven-resolver/blob/362a43675f01b8bb3d85d7b0ff76a21d57de6fee/maven-resolver-api/src/main/java/org/eclipse/aether/resolution/VersionRangeResult.java#L102 > >
