Mailing-List: contact dev-help@archiva.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@archiva.apache.org
Received-SPF: pass (athena.apache.org: domain of odeaching@gmail.com
 designates 209.85.212.170 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=jGJH52C07fBaxiHhwbIq681GJw/1pM9/oQOCnv/5lNebAxR4LrbXt99rHdKB5rpU7C
         VEKojI74iDtsMi7uNpU/LuaFw6ekdcFgj7EI3PHZys5WSMqe1c4Ze+x3mc+jRCLNIckm
         DGCfMsnOAI/r4TsSNA/kBZNBpOAAUTRf6WlkI=
MIME-Version: 1.0
Sender: odeaching@gmail.com
In-Reply-To: <x2w1e57ba6c1004281244i3de97ed5j8e5c044e2075f43d@mail.gmail.com>
References: <n2hadba96191004021347r94d90fd4v62286182cadee1b7@mail.gmail.com>
	 <CC61FC7E-136B-4385-A76C-9AE5713A1CDA@apache.org>
	 <g2m1e57ba6c1004120003t3a8c77abj7f1791dde4dbee0@mail.gmail.com>
	 <y2k8667b1bd1004120130mf97d7647x8712077a185cc0b7@mail.gmail.com>
	 <1288C6E7-94AA-4579-ADFD-23111DE7FACD@apache.org>
	 <F723A9E6-C587-42CF-B99B-6EB9AF8768DD@apache.org>
	 <r2m8667b1bd1004200226r4e776d92ked060892de0655d8@mail.gmail.com>
	 <u2u1e57ba6c1004200933rc567114eq7d78e700b36f3672@mail.gmail.com>
	 <4E9698FC-A586-4211-B5A4-70EDAFB2E3E9@apache.org>
	 <x2w1e57ba6c1004281244i3de97ed5j8e5c044e2075f43d@mail.gmail.com>
Date: Thu, 29 Apr 2010 10:03:53 +0800
Message-ID: <p2p8667b1bd1004281903yff13438fza9b26bc248c2bd3f@mail.gmail.com>
Subject: Re: Staging repositories (was: Re: GSoC projects?)
From: Deng Ching <oching@apache.org>
To: dev@archiva.apache.org
Content-Type: multipart/alternative; boundary=00504502e53ee454f1048556897e

--00504502e53ee454f1048556897e
Content-Type: text/plain; charset=ISO-8859-1

Hi Eshan,

Can you update the wiki directly with the changes that you specified in the
attachment? The wiki is version controlled so it shouldn't be a problem to
track changes made in the page.

Thanks,
Deng

On Thu, Apr 29, 2010 at 3:44 AM, Eshan Sudharaka <esudharaka@gmail.com>wrote:

> hi brett,
> i have added a attachment to the proposal on wiki.I need a review and then
> i
> am willing to edit the proposal.
> link to the attachment<
> https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=18153606&metadataLink=true
> >
>
> thank you.
>
> On Wed, Apr 28, 2010 at 7:46 PM, Brett Porter <brett@apache.org> wrote:
>
> >
> > On 21/04/2010, at 2:33 AM, Eshan Sudharaka wrote:
> >
> > > hi,
> > > I just added the gsoc proposal to the apache wiki(with out doing any
> > > change).
> > >
> >
> https://cwiki.apache.org/confluence/display/ARCHIVA/Staging+Repository+Merge
> >
> > I cleaned up the content to use wiki syntax and remove the GSOC specifics
> > (that can all be tracked separately - we just want to work on the
> technical
> > proposal here). I haven't made any changes to the content itself.
> >
> > I'd like it if you were able to make most changes to the doc based on
> what
> > we discuss here. There's a few posts in the thread to pick up ideas from.
> >
> > There's also plenty of questions to answer and adjust based on the thread
> > so far:
> > - are the repositories temporary or permanent, and how do they get
> created?
> > - how will promotion work? what different options are there? (as Deng
> > pointed out, the audit logs are probably not the right approach here)
> > - how does a failed deployment get cleaned up?
> > - what permissions are needed exactly?
> >
> > I addressed my thoughts in some previous messages. But don't feel like
> you
> > have to agree with me - the point here is to discuss alternatives and all
> > convince each other until we find the best solution.
> >
> > I previously posted this:
> > http://people.apache.org/~brett/staging-promotion.png<http://people.apache.org/%7Ebrett/staging-promotion.png>
> <http://people.apache.org/%7Ebrett/staging-promotion.png>.
> > That has an assumption of permanent staging repositories - which is an
> > advantage that the URL is always the same and doesn't require some
> > finalisation to be active, but has a disadvantage that you might mix
> > releases. One way to handle that problem is to have artifact-level
> control
> > of what gets promoted (which you can make smart by reading the Maven
> > metadata and finding out which modules are related to each other). I
> > discussed that more in the previous email.
> >
> > One other thing to note: repositories are not necessarily Maven 2. Things
> > like Maven metadata merging should be handled by the repository API
> > abstraction, rather than being baked into the code. I'm happy to help
> > discuss the design of this once we get past the "user level" ideas.
> >
> > Cheers,
> > Brett
> >
> > --
> > Brett Porter
> > brett@apache.org
> > http://brettporter.wordpress.com/
> >
> >
> >
> >
> >
>
>
> --
> P.A.Eshan Sudharaka
> Dept of Computer Science and Engineering
> University of Moratuwa
> Sri Lanka
>

--00504502e53ee454f1048556897e--