Thanks for the insight, Robert.

The terminology in my original email was skewed, as I had erroneously
thought that resolving was just finding an artifact on a repo from given
coordinates; from what you've said, resolving is obviously both finding &
downloading a copy of the artifact.

The tricky thing here are versionRanges, don't think there's an explicit
> term other than "coordinate with version ranges"


For brevity, might "ranged coordinates" be an acceptable abbreviation of
"coordinates with version range"?

An artifact is a reference to a file, either resolved (downloaded) or
> unresolved.


Is an artifact:

 - coordinates + repo
 - coordinates + resolved file name + resolved file contents
 - coordinates + resolved file name + resolved file contents + repo
 - resolved file name + resolved file contents (e.g., different coordinates
can map to the same artifact)
 - resolved file contents
 - something else

Coordinates are always valid, resolvable, etc.


I think that there is some use in distinguishing between categories of
coordinates, e.g.:

 - resolvable
        coordinates that correspond to an artifact (on at least one of the
specified repos)
 - unresolvable
        coordinates that do not correspond to an artifact (on any of the
specified repos)
 - incomplete
        coordinates that are missing groupId, artifactId, or both
 - versionless
        coordinates that are missing version (this is useful in non-POM
contexts like Gradle)

One could argue there's also a resolvable state [for artifacts], i.e. not
> yet downloaded but confirmed it exists, either via metadata or a HEAD
> request


I think that the "resolvable" artifact state is useful.

Reply via email to