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.