Op Sun, 12 Jul 2015 22:08:22 +0200 schreef Hervé BOUTEMY
<[email protected]>:
Le dimanche 12 juillet 2015 20:26:36 Robert Scholte a écrit :
While working on maven-artifact-transfer (the independent Aether version
bridge) and trying to use it for several plugins I came across some
issues, especially when transitive dependencies are required.
IMO an Artifact is a reference to a File based on coordinated (GAV +
type,
which translates to an extension, sometimes with classifier). An
artifact
is considered resolved if the File is downloaded.
The artifact itself has no knowledge about transitivity, that's part of
the descriptor. Hence there's no such thing as transitive artifacts.
However,there are a lot of plugins interested in all the transitive
dependencies.
Only for Objects like MavenProject, Plugin (which have dependencies) it
makes sense to ask for such dependencies.
However, a MavenProject is a fully populated instance, which is often
too
much if somebody just wants to have all transitive dependencies for a
specific GAV (or Artifact, but I'd like to avoid this term).
that's why we need a simple API to calculate transitive dependencies for
an
artifact, doing just what's necessary to get that
It looks like Artifact is often abused for too much information.
yes, Maven Artifact is not really well documented (no javadoc at all),
and has
methods of constants both for GAV and for dependencies
Aether
already separated resolveArtifact() and resolveDependencies().
Up until now we used to make usage of the ArtifactFactory, but that
class
is deprecated.
the more I think about it, the more I think this deprecation was just in
the
spirit of using Aether: but since we need the bridge for multiple Aether
version, IMHO we should simply remove the deprecation (or better explain
the
idea behind it and target APIs)
What I like about RepositorySystem are the clean methods to generate an
artifact. But the choice between ArtifactRepository or RepositorySystem is
not going to help us for the Maven3 compatible plugins.
Probably the original need for an ArtifactFactory is the ArtifactHandler
required to translate a type/packaging to an extension. The
ArtifactHandler is injected into the Artifact, which makes it quite hard
to transform an Artifact into a simple pojo.
Today I discovered the org.apache.maven.repository.
RepositorySystem to create Artifacts, but there's only 1 implementation:
org.apache.maven.repository.legacy.LegacyRepositorySystem, which is
again
part of maven-compat.
Is it still an Artifact we want to create when we are interested in
transitive dependencies?
why not?
Based on my suggested definition an Artifact means GAV + file reference.
An Artifact holds file location information for Objects like MavenProject,
Plugin, Dependency. With architectural glasses *these* Objects have the
transitive dependencies and not an Artifact. Using the coordinates of an
Artifact to obtain some root object with dependencies, which is then used
to collect the transitive dependencies seems wrong/lazy, but it works.
IMHO, when we use an (o.a.m.a.)Artifact, we're trying to have
compatibility,
then we can't avoid this class
This compatibility expectation makes that we can't whange the API:
perhaps we
should start by documenting which part of the API is part of dependency
handling: that would be a starting point
Of course, while at it with maven-artifact-transfert, we could include a
dedicated API in this component
I was indeed thinking of a dedicated API, but since the Artifact interface
has become one of the most important interfaces of Maven it's hard to
change it.
thanks,
Robert
If so: what's the preferred way? RepositorySystem, which should also
get a
non-legacy implementation?
If not: should we introduce something like
ArtifactDescriptor/ArtifactStructure?
IMHO, just un-deprecate ArtifactFactory
Regards,
Hervé
Is there a reason why there's no interface for GAV instances usable for
Objects like MavenProject, Plugin and Dependency and Artifact
thanks,
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
