maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlos Sanchez" <car...@apache.org>
Subject Re: [embedder] Retrieving available versions of an artifact
Date Fri, 06 Apr 2007 17:48:03 GMT
I opened MNG-2940

The only methods I see using MavenExecutionRequest is execute and
readProjectWithDependencies. I don't see how useful would be using it
as parameter.
Same to return MavenExecutionResult, there's no project or reactor,
and to encapsulate the possible exceptions, they are already in
MavenEmbedderException


On 4/5/07, Jason van Zyl <jason@maven.org> wrote:
>
> On 5 Apr 07, at 12:56 PM 5 Apr 07, Carlos Sanchez wrote:
>
> > On 4/5/07, Jason van Zyl <jason@maven.org> wrote:
> >>
> >> On 5 Apr 07, at 12:26 PM 5 Apr 07, Carlos Sanchez wrote:
> >>
> >> > I need it the same way the cli would do it, for version ranges,
> >> > snapshots,... I need the metadatasource
> >> >
> >>
> >> You still haven't answered the question as to the specific use case.
> >
> > it's a library that given group and artifact expects a list of
> > versions. As it may later be used by maven i want to be consistent
> >
> >>
> >> > It is already abstracted in ArtifactMetadataSource interface
> >>
> >> This interface cannot be exposed via the embedder, if you want to
> >> return an ordered Set of versions that's fine.
> >
> > So you are suggesting adding this method from ArtifactMetadataSource
> > to the embedder
> >
> >    List retrieveAvailableVersions( Artifact artifact,
> > ArtifactRepository localRepository, List remoteRepositories )
> >        throws ArtifactMetadataRetrievalException;
>
> No.
>
> - the result should be a result of some sort container a Set, you
> have to trap exceptions and return a result for useful embedding
> - it should follow the conventions of the other methods i.e. using a
> MavenExecutionRequest
> - the method should be more clear. "retrieveAvailableVersions" of
> what it makes me ask, and
> - no exposing internal exceptions
>
> So, you should have something like
>
> MavenExecutionResult getArtifactVersions( Artifact artifact,
> MavenExecutionRequest request ) throws
>          MavenEmbedderException
>
> Look at the readProjectWithDependencies as an example but using the
> request makes sure a consistent setup is used for all the method
> calls with the embedder. This has allowed us to achieve consistency
> between querying and execution so any methods added need to follow
> the same pattern.
>
> So we may need to look at a different result type, you can't just
> return the data because anything could go wrong during the lookup and
> you have to provide information for clients to respond.
>
> That's the rough guide, when you have something in your branch I will
> take a look. We can't just jam methods into the embedder. The
> ExecutionRequest is mandatory is method calls and a result of some
> form. This coincides with what I'm going to be adding so that a
> client can query the lifecycle and I will need a new type of result
> there too. So hack away and I'll help you sync up.
>
> Jason.
>
>
> >
> >
> >>
> >> > , so if
> >> > you want to add the index as another source right now you'd just
> >> need
> >> > to make a new implementation.
> >>
> >> I expect anything you are working on will be put in a feature branch
> >> in the sandbox for review so I will look at it as the embedder
> >> interface already needs to slim down and I'm adamant about not
> >> exposing any internal API or structures, in particular anything to do
> >> with maven-artifact because anything dependency related has to move
> >> to a graph structure as what is present is fraught with problems.
> >
> >
> > I just need that method, nothing else. I don't actually need the
> > metadata source exposed, what I need is it to be used as the cli does
> >
> >
> >>
> >> So in your particular case a query by groupId+artifact id should
> >> yield a set of versions. So exposure of ResolutionGroup,
> >> MetadataSources or anything else.
> >>
> >> Jason.
> >>
> >> >
> >> > On 4/3/07, Jason van Zyl <jason@maven.org> wrote:
> >> >> On 3 Apr 07, at 4:55 PM 3 Apr 07, Carlos Sanchez wrote:
> >> >>
> >> >> > I need this to get a list of versions available for an
> >> artifact. I
> >> >> > want to do it the same way maven does to avoid inconsistencies,
> >> >> so the
> >> >> > index is not an option.
> >> >>
> >> >> If this is for releases which is probably what the you want
> >> there are
> >> >> no inconsistencies and the index is actually far more reliable.
> >> >>
> >> >> If you want up-to-date snapshots then that's a different story
> >> but I
> >> >> can't see the vast majority of people doing production development
> >> >> work being interested in that.
> >> >>
> >> >> If you want snapshot support then it would have to be dynamic
> >> as the
> >> >> index is only updated on a daily basis.
> >> >>
> >> >> This should be abstracted anyway because in the future I think
> >> >> leveraging the tiny index that can be pulled down locally would
> >> >> provide an artifact resolution mechanism that is far more reliable
> >> >> and an order of magnitude faster.
> >> >>
> >> >> Jason.
> >> >>
> >> >> >
> >> >> > On 4/2/07, Jason van Zyl <jason@maven.org> wrote:
> >> >> >>
> >> >> >> On 2 Apr 07, at 8:22 PM 2 Apr 07, Carlos Sanchez wrote:
> >> >> >>
> >> >> >> > I haven't found a direct way to retrieve the
> >> >> ArtifactMetadataSource
> >> >> >> > instance to retrieve the list of available versions in
the
> >> >> >> repository,
> >> >> >> > I have to explicitly look it up in the plexus container.
> >> >> >> >
> >> >> >> > Did I miss something? if not it would be useful to expose
the
> >> >> >> > ArtifactMetadataSource or add a getAvailableVersions
method
> >> >> to the
> >> >> >> > embedder
> >> >> >>
> >> >> >> What's the full use case?
> >> >> >>
> >> >> >>   People typically use the search with the index to find all
> >> the
> >> >> >> available versions to, say, select a specific version of
> >> commons-
> >> >> >> logging. This is for the IDE and is specific to that
> >> environment.
> >> >> >>
> >> >> >> The indexing API will be exposed in a package at Mevenide
and
> >> >> not in
> >> >> >> the embedder, but that is the way users have generally been
> >> seeing
> >> >> >> all versions and that's how users interact with the artifact
> >> >> >> selection process. It's far easier using the index which is
> >> 300k
> >> >> >> zipped for the entire repository.
> >> >> >>
> >> >> >> Jason.
> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> >    public List<ArtifactVersion> getAvailableVersions(Artifact
> >> >> >> > artifact, List<ArtifactRepository> remoteRepositories,
> >> >> >> > ArtifactRepository localRepository)
> >> >> >> > {
> >> >> >> >
> >> >> >> > ArtifactMetadataSource artifactMetadataSource =
> >> >> >> > (ArtifactMetadataSource) mavenEmbedder.getPlexusContainer
> >> >> ().lookup(
> >> >> >> >                        ArtifactMetadataSource.ROLE);
> >> >> >> >
> >> >> >> >            return
> >> >> >> > artifactMetadataSource.retrieveAvailableVersions(artifact,
> >> >> >> > localRepository, remoteRepositories);
> >> >> >> > }
> >> >> >> >
> >> >> >> > --
> >> >> >> > I could give you my word as a Spaniard.
> >> >> >> > No good. I've known too many Spaniards.
> >> >> >> >                             -- The Princess Bride
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> > 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
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> > --
> >> >> > I could give you my word as a Spaniard.
> >> >> > No good. I've known too many Spaniards.
> >> >> >                             -- The Princess Bride
> >> >> >
> >> >> >
> >> >>
> >> ---------------------------------------------------------------------
> >> >> > 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
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > I could give you my word as a Spaniard.
> >> > No good. I've known too many Spaniards.
> >> >                             -- The Princess Bride
> >> >
> >> >
> >> ---------------------------------------------------------------------
> >> > 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
> >>
> >>
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> >                             -- The Princess Bride
> >
> > ---------------------------------------------------------------------
> > 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
>
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message