archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deng Ching <och...@apache.org>
Subject Re: [GSoC] Staging repositories updates
Date Wed, 23 Jun 2010 06:58:18 GMT
On Wed, Jun 23, 2010 at 2:27 PM, Brett Porter <brett@apache.org> wrote:

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


Right, sorry I forgot that we've decided to create the staging repos as
"shadows" of a managed repo.


> Or do we want to accommodate any promotion workflow?


Maybe as a future enhancement to consider?


>
> 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)
>
> HTH,
> Brett
>
>
Thanks for the additional input :)

-Deng

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message