On Fri, Jun 18, 2010 at 12:22 PM, Brett Porter <[email protected]> wrote:
> > On 17/06/2010, at 3:07 PM, Deng Ching wrote: > > > A couple of things I noted down for the new repository API while working > on > > the generic metadata: > > 1. further improvements on generic metadata: > > - metadata can be displayed by category (hierarchical) for easier > > viewing > > This would be if you want to view all the metadata, instead of the generic > one (which is not hierarchical, unless you change the way it is handled). > > > - implement a new plugin for the rating instead of including this in > the > > generic metadata (which is shown as key-value pairs) as suggested by > Brett > > What I meant here is that if you want to do something on repeated > instances, it'd be better to have a plugin (and standard namespace), that > can validate the data and do more complicated handling, rather than > requiring some additional naming convention. These are pretty simple pieces > of code after all - but the generic one is still useful for those that want > to just use a particular annotation internally without any new code. > > > 2. make the location of the metadata repository (currently stored in the > > file system) configurable > > The file-based implementation is still only a proof of concept anyway - if > we decide to harden that and use it I agree. But I personally would like to > try and make JCR work and see how well it performs. > > > - one potential problem with having the default location in the root > > directory of the actual repository is that the metadata repo can get > > included if you run merge the Archiva repo to another repo (ex., running > mvn > > stage:copy in a staging repo) > > > I think this is a fault of that goal more than Archiva :) That shouldn't > impact the merge implementation happening now. We ignore all those in the > scanning. > Sorry, I didn't mean the repo merge feature in Archiva but rather when you run mvn stage:copy (like when we're releasing Archiva :) Thanks, Deng
