Mailing-List: contact dev-help@archiva.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@archiva.apache.org
Received-SPF: pass (nike.apache.org: domain of odeaching@gmail.com designates
 209.85.212.42 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type;
        b=kj4nxiXH5cmmvEyqkp36eSiAn3EgV9JUMkZawuczfx5h3LLmi6cav/ftpmyxhIG58w
         t/b9NeqDoQ7vGkyuDvN3iCW2pUNKVOMEMXpQJRvUcVlL4i2HutpggZvxbtWKVbXX3Hme
         7H5fw6XASykHURY1vjzREPhXQaVcpGQb7ON20=
MIME-Version: 1.0
Sender: odeaching@gmail.com
In-Reply-To: <43D11043-D3D5-4656-8DC8-AABE011A8FE4@apache.org>
References: <AANLkTikzN6MqSSMQWjtQxGYL4q4ozpO0_kvmy6hqDZyL@mail.gmail.com>
	<43D11043-D3D5-4656-8DC8-AABE011A8FE4@apache.org>
Date: Fri, 18 Jun 2010 12:49:33 +0800
Message-ID: <AANLkTikw66qmf4GTVYFNo7xCrofdEY65GnVVRb4qomlR@mail.gmail.com>
Subject: Re: A few notes on new repository API
From: Deng Ching <oching@apache.org>
To: dev@archiva.apache.org
Content-Type: multipart/alternative; boundary=00163631011f689376048946ae6d

--00163631011f689376048946ae6d
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Jun 18, 2010 at 12:22 PM, Brett Porter <brett@apache.org> 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

--00163631011f689376048946ae6d--