On Fri, 08 Jun 2018 21:02:29 +0200, Ross Goldberg
<[email protected]> wrote:
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.
It is a two-phase thing: collecting and resolving.
Collecting is used when you need to include all transitive dependencies
too.
After that the resolving starts.
That said: resolving an artifact means you know all the details and it
points to 1 file
If you are interested in a dependency/plugin/extension you're also
interested in the transitive dependencies (otherwise you should have
picked the artifact directly). In this case the collecting is done,
including version resolution.
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"?
I guess that is acceptable. Can't think of a better term, although it is
only the version that is ranged. e.g. there's an option to exclude all
dependencies with <exclusions/>. Here you can use * for all groupIds and
artifactIds. But maybe that case deserves its own name.
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
The unresolved artifact has a coordinate and based on the file name can be
calculated.
The resolved artifact also contains the repo and the resolved file
contents.
When an artifact with a SNAPSHOT version must be resolved, it first checks
if the file exists with the specified version, otherwise it'll download
metadata from the remote repository and pick the best matching version.
that will be the resolved filename.
It all depends on the state of the artifact.
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
incomplete and versionless coordinates will stop Maven (for plugins it is
allowed, but you get a warning) because they can never be resolved.
This is all within the Maven context, I have no idea how other tools
define their entities.
I think that the "resolvable" artifact state is useful.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
