Mailing-List: contact archiva-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: archiva-dev@maven.apache.org
Received-SPF: pass (athena.apache.org: domain of bellingard@gmail.com
 designates 209.85.198.191 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=PEBxnzMKrRHGRNHc+/TVNZFKLN6M++HsnsGLBD34iStFoJoZEdMh8TSUsIqLrFTrKQH26WyvRurJkDkc12ef/zDw+ZQvaPx8PaNk5ORtQ5vcQk4FntLujrLpEtrKaLDBxEWhZafMUZbmAuVvU2WqEE8dWjcxPCJ08cOcc3JT/hw=
Message-ID: <760712e50802040242u1daae170q7207d2085e8066a0@mail.gmail.com>
Date: Mon, 4 Feb 2008 11:42:14 +0100
From: "Fabrice Bellingard" <bellingard@gmail.com>
To: archiva-dev@maven.apache.org
Subject: Re: Archiva 1.1 Roadmap
In-Reply-To: <4c39e3030802040038q6880a0bdo9dbf96a84407250d@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_3310_22369338.1202121734858"
References: <1202105219.28501.40.camel@heck>
	 <1a57a2980802040028i325bf798s88deceb9a0fea475@mail.gmail.com>
	 <4c39e3030802040038q6880a0bdo9dbf96a84407250d@mail.gmail.com>

------=_Part_3310_22369338.1202121734858
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Nicolas,

concerning your "maven" managed repository: are you currently really doing
that with archiva? It seems indeed interesting, as it simplifies the
configuration of the settings.xml file. However, I have a couple of
questions:
- this means that this "maven" repository duplicates every artifact handled
in your other managed repositories, right? So when you browse artifacts in
Archiva, you see managed artifacts twice, don't you?
- do you use the same principle for snapshots repositories? I mean, metadata
files would conflict with release repositories, so you need another
"virtual" repository for snapshots.

Fabrice

On Feb 4, 2008 9:38 AM, nicolas de loof <nicolas@apache.org> wrote:

> Early version of archiva had on admin menu a "sync repository" entry.
>
> Not sure if the original idea was to manage a classical rsync-like miror
> or
> to isolate local cache for remote proxied repositories.
>
>
> I would suggest some "virtual" repository
>
> A simple example is my corporate use case : many user don't know maven
> well
> and have no idea what a repository is (and how to configure), so we have
> configured settings.xml to mirror all common repositories to the archiva
> instance : http://server/archiva/repository/maven
>
> The "maven" managed repository is an aggregate of proxied (central,
> java.net,
> jboss, ...) and managed ones : corporate builds, restricted jars (SUN
> apis,
> oracle driver) and sources bundles (missing in public repos)
>
> This repository, declared in archiva configuration as "managed" is NOT the
> one we have to manage ! It only is a facade to other managed and proxied
> repositories.
>
>
> Nico.
>
> > >
> > > One item I wanted to single out is the separation between managed
> > > repositories used for publishing and those used for caching artifacts
> > > from remote repositories. I don't think it makes much sense to have a
> > > managed repository that can do both.
> >
> >
> > a big +1 here :) a lot of people has been confused over this especially
> > when
> > there are quite a handful of repositories being managed.
> >
> >
> > >
> > >
> > > This separation would allow us to have:
> > > * Provide indexing, browsing and search only for "publishing" (See
> foot
> > > note)
> > > * RSS feeds for new artifacts in published repositories.
> > >
> > > Foot note:
> > > Allowing to search proxied data is a broken idea - its an incomplete
> > > view of a remote repositories and when your dealing with tens of
> > > gigabytes of metadata and artifacts this becomes painful and slow.
> > >
> > > Anyway, I look forward to your comments.
> > >
> > > Thanks,
> > > James Dumay
> > >
> > >
> > Thanks,
> > Deng
> >
>

------=_Part_3310_22369338.1202121734858--