archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deng Ching <>
Subject Re: A few notes on new repository API
Date Fri, 18 Jun 2010 04:49:33 GMT
On Fri, Jun 18, 2010 at 12:22 PM, Brett Porter <> 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 :)


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