archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: [GSoC] Staging repositories updates
Date Wed, 23 Jun 2010 06:27:35 GMT

On 21/06/2010, at 12:02 PM, Deng Ching wrote:

> Just to get everyone updated on where we are on the staging repositories..
> Last Saturday, we reviewed and revised the patch that was submitted for
> MRM-980. The patch contains the new module for the repo merge, with the
> class for getting the artifacts in the source repo implemented.

I'll take a look at this.

> One of the
> things that was encountered in using the new repository API was having to do
> nested loops through the namespace, project & version then through a list of
> ArtifactMetadata in order to get the artifacts. (Brett, is there an easier
> way to do this?)

That's how it's designed for now, but we definitely want the iteration hidden in the repository
abstraction so that we can later make it more efficient. If you look at the implementations
in FileMetadataRepository for the getArtifactsBy* methods that's what they do. I recommend
adding a getArtifacts(String repoId) method to the MetadataRepository (not the resolver -
we don't want to traverse a proxy repository!) to accommodate this. 

Actually, even better would be to change the current getArtifactsBy* methods to getArtifacts(
String repoId, Filter filter ) and convert the others to have a date / checksum filter. That
makes it a bit more extensible and we just need to be able to apply the filter to other implementations
(eg a lucene index or a JCR repository) since iterating properties files is not scalable :)
I'll take note of this - it's not needed for your case.

> The next item that needs to be done now is to implement the repository merge
> API. As a starting point, here are the test cases that we've identified
> which needs to be covered:

looks good, just one point:

> - repositories have different layouts (ex. source repo is legacy type,
> target repo is default type)

I don't think this is initially necessary (nor is Maven 1 / Maven 2, etc). Even though the
repository API should handle these cases, in practice aren't we creating the staging repos
as "shadows" that can implicitly have the same format? Or do we want to accommodate any promotion

A couple more comments from what I've seen so far:
- you should never have to deal with Maven metadata files or checksum files to make this work
(As other repository formats may not have them). The Maven2 implementation should already
be dealing with that when you say you want to store an artifact and its attachments.
- the merge plugin should not have any Maven knowledge - it should really be dealing with
getting stuff out of one repository (Exists in the repository API, with modifications as above)
and putting it into another (hasn't been dealt with yet and requires work for proxying and
deployment migration as well). So as a starting point it's incredibly basic (get list of stuff,
pass to another API to store). The tricky bit we want up front is dealing with error conditions
(does it rollback, skip?). Going forward we might have more (handling workflows, adding hooks
around the process to process things)


Brett Porter

View raw message