Re: [embedder] Retrieving available versions of an artifact

Thu, 05 Apr 2007 11:13:56 -0700 


On 5 Apr 07, at 12:56 PM 5 Apr 07, Carlos Sanchez wrote:


On 4/5/07, Jason van Zyl <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>> >> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> --------------------------------------------------------------------- 
>> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>
>> >>
>> >
>> >
>> > --
>> > I could give you my word as a Spaniard.
>> > No good. I've known too many Spaniards.
>> >                             -- The Princess Bride
>> >
>> >
>> --------------------------------------------------------------------- 
>> > 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]
>>
>>
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                             -- The Princess Bride
>
> --------------------------------------------------------------------- 
> 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]





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

---------------------------------------------------------------------
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]

Reply via email to