archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deng Ching <och...@apache.org>
Subject Re: Staging repositories (was: Re: GSoC projects?)
Date Thu, 29 Apr 2010 02:03:53 GMT
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
>

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