On Wed, Jun 23, 2010 at 2:27 PM, Brett Porter <[email protected]> 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
