gnodet commented on code in PR #1391:
URL: https://github.com/apache/maven/pull/1391#discussion_r1466386770
##########
api/maven-api-core/src/main/java/org/apache/maven/api/Artifact.java:
##########
@@ -105,6 +105,14 @@ default String key() {
*/
boolean isSnapshot();
+ /**
+ * The artifact properties.
+ *
+ * @return the artifact properties, never {@code null}
+ */
+ @Nonnull
+ ArtifactProperties getArtifactProperties();
Review Comment:
> Resolver also encodes "type" in Artifact#properties. It also exposed since
eons ctors for DefaultArtifact where you could pass in ArtifactType. The type
you declare (i.e. if in project, you have packaging -> type) or if "ad-hoc" by
root dependency node type (where callar knows what it does).
>
> Or in short:
>
> * artifact is a file decorated with coordinates and properties
> * dependency is an artifact having extras like scope, type, optionality
using which you can "derive" an artifact as above
> * true, in Resolver "dependency" is ONLY a thing that comes from POM
(ArtifactDescriptor) but it is being distilled to artifact (as in second bullet
-> first bullet).
>
> Basically "everything is an artifact", and "dependency is an artifact that
enters the game as dependency". This is how Resolver abstracts.
Yes, and I think that's where some confusion comes from. Everything is an
artifact means that when you have an Artifact object, you don't really know
what it is: it can be 5 different things:
* a pointer to a file (with a version range): ArtifactCoordinate
* a resolved artifact in a repository (a definite version): Artifact
* a pointer to a dependency (version range + scope + type)
* a resolved dependency: the resolver actually has
`org.eclipse.aether.graph.Dependency` and that's what the v4 api wraps
* an artifact generated by the project
> Doing collect+resolve operation and ending up with list of sole
Dependencies is what you say?
This is also a confusing part. It's conceptually a 3 step process: collect
+ flatten + resolve. The collect grabs the input and computes the graph of
Node. Flattens will output a *list* of Node. Then the resolution step becomes
the same as the _artifact resolution_ because each node can be turned into an
artifact coordinate, and we then just download the actual artifacts.
In the v4 api, we have `ArtifactResolver` which gives an `Artifact`. The
`DependencyCollector` returns the graph with `Node`s. The
`DependencyResolver` performs both `flatten` which gives an ordered list of
`Node`s, and `resolve` which returns an ordered `Map<Dependency, Path>` which I
think is what is needed to compute the build paths.
> When you collect+resolve, you are interested in all, so even root (again,
this is for "ad-hoc" operations, like javadoc may tell: "resolve me this taglet
and its dependencies", in that case, javadoc plugin KNOWS root is taglet, but
will still need to handle the rest of transitive hull, and place them or use
that as needed).
>
> @gnodet if I understand you correctly, sans "root", you consider
_everything else_ (the transitive hull) as "dependency"? Which kinda makes
sense, as they DID enter the result collection as "dependencies of root"?
Yes, everything is a dependency. It's only the root which can be a project
or artifact, but when you collect the dependencies for a project or artifact,
you actually resolve all its *dependencies*.
I think there may be a small piece missing, which is the ability to access
the graph from a dependency, i.e. adding a `Node getNode()` on the
`org.apache.maven.api.Dependency` to get back to the graph.
At some point, I did envision to call it `ResolvedDependency` which would
avoid the confusion with the _model dependency_, which is is translated into a
`DependencyCoordinate`, the collected / flattened / resolved.
To sum up: the v3 api lacks a bunch of things, that's why plugins have to
use the resolver to get fine grain access to the resolution output. The v4 api
aims to expose those bits, but those aren't really new, the
`org.apache.maven.api.Dependency` simply wraps
`org.eclipse.aether.graph.Dependency`. That was clearly a missing piece in the
v3 api.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
