You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Robert Scholte <co...@sourcegrounds.com> on 2015/07/12 20:26:36 UTC
The definition of Artifact
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).
It looks like Artifact is often abused for too much information. Aether
already separated resolveArtifact() and resolveDependencies().
Up until now we used to make usage of the ArtifactFactory, but that class
is deprecated. 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?
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?
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: The definition of Artifact
Posted by Robert Scholte <rf...@apache.org>.
Op Sun, 12 Jul 2015 22:08:22 +0200 schreef Hervé BOUTEMY
<he...@free.fr>:
> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: The definition of Artifact
Posted by Hervé BOUTEMY <he...@free.fr>.
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)
> 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?
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
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org