archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: Staging repositories (was: Re: GSoC projects?)
Date Mon, 19 Apr 2010 01:29:57 GMT
It looks like the wiki is back up now. Perhaps it's a good time to transfer the proposal over
there and edit in some of the comments from the thread?

- Brett

On 13/04/2010, at 12:26 PM, Brett Porter wrote:

> 
> On 12/04/2010, at 6:30 PM, Deng Ching wrote:
> 
>> On Mon, Apr 12, 2010 at 3:03 PM, Eshan Sudharaka <esudharaka@gmail.com>wrote:
>> 
>>> Hi brett,
>>> as i understood if we create a new repo then a staging repo is
>>> automatically created.And deployment is according to following order.
>>> stage _ test_repo > test_repo > internal repo or snapshot repo
>>> 
>>> 
>> I think this should be just stage_test_repo > managed repo (internal,
>> releases, etc.)?
> 
> Yep. To better articulate what I was trying to say, maybe a diagram would help:
> http://people.apache.org/~brett/staging-promotion.png
> 
>> 
>> Also, as an additional comment to this line in the proposal..
>> 
>> *  "Here i am going to use archiva audit logs to determine what is the
>> suitable option to follw and provide above functionalies to the user.*"
>> 
>> I think it would be best to have a UI to present or give the user an option
>> which artifacts he/she may merge. I don't think you would need to
>> necessarily base it on the audit logs since their purpose are mainly for
>> tracking changes.
> 
> Yep. What I was thinking when promoting was that you'd start at a particular artifact
and if it is in a staging repository a promote button appears if you have permission. That
would bring up a page with some options:
> - promote all children in the staging repository (that is, by traversing <modules>
- listed, and on by default)
> - promote all dependencies / parents in the staging repository (listed, and off by default)
> 
> Alternatively there could be a repository option to promote the whole repo, probably
accessible from the sidebar and offering a dropdown of staging repositories with content and
which you have promote access.
> 
> Another use case is to delete a failed deployment - the existing delete option can be
used for that, and we might talk about improving it (possibly by reusing the above UI).
> 
> What do others think about this? Are there other use cases?
> 
> As an implementation detail, as much as possible should be contained to the repository-api
and a new plugin, with just the UI in the webapp.
> 
> I'll add some further comments on the proposal later.
> 
> - Brett
> 
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> 
> 
> 
> 

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/





Mime
View raw message