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 <[email protected]> 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>. > 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 > [email protected] > http://brettporter.wordpress.com/ > > > > > -- P.A.Eshan Sudharaka Dept of Computer Science and Engineering University of Moratuwa Sri Lanka
