You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@archiva.apache.org by Eshan Sudharaka <es...@gmail.com> on 2010/05/01 04:57:59 UTC
proposal for stage repository
hi all ,
I have prepared a proposal for add stage repository for apache archiva.And
it is selected for the google summer of code 2010.Here is the link to the
proposal.
https://cwiki.apache.org/confluence/display/ARCHIVA/Staging+Repository+Merge
It will be more useful for me to understand the missing parts and the
conflicts by going through the comments.So all are warmly welcome to share
ideas to make that thing a success.
thank you.
--
P.A.Eshan Sudharaka
Dept of Computer Science and Engineering
University of Moratuwa
Sri Lanka
Re: proposal for stage repository
Posted by Dan Tran <da...@gmail.com>.
if basic merge feature between any 2 repositories works first using
admin repository admin role, it would be awesome.
then deliver security/access details later.
-
On Mon, May 3, 2010 at 11:50 PM, Brett Porter <br...@apache.org> wrote:
> On 01/05/2010, at 12:57 PM, Eshan Sudharaka wrote:
>
>> https://cwiki.apache.org/confluence/display/ARCHIVA/Staging+Repository+Merge
>>
>> It will be more useful for me to understand the missing parts and the
>> conflicts by going through the comments.So all are warmly welcome to share
>> ideas to make that thing a success.
>
> Looking good.
>
> Here are some more comments:
>
>> I think in the stage repository we should limit the access. Nobody should allow to download the artifacts in the staging repositories other than the developers,QA people, archiva admin user ,and the the guy who have the permission for the promotion.
>>
>> I think it is the repository manager's task to create the stage repositories and attach it to the main repository that he want to add the staging functionality.
>
> I generally agree with this, but maybe it should be more general - those might be the defaults, but it's really a matter of specifying how the roles and permissions relate and can be assigned. Does that make sense?
>
> This started to be covered in the next section, but that also talks about the behaviour - maybe it would be better to rephrase these as 'stories' for users in certain roles (this will help break it up into tasks to complete as well).
>
>> If the artifact is an existing one(latest version) we need to provide following options.
>
>
> I'm not sure about these options. I think we can honour the current repository configuration - that is either just let it replace, or block it as not allowed to overwrite existing releases.
>
>> But if there are no significant changes in both artifacts then it is better to remove the version 1.3 and add 1.4.
>
>
> I don't think Archiva should get into this judgement call here - old releases need to stay around (and the existing delete functionality is there if there is a need to remove old things for some reason).
>
> BTW, will merging be meaningful for snapshot repositories?
>
> In the implementation, some of the above is covered and there is more like:
>
>> add the simultaneous deployment functionality for the stage repositories.(here need to find a way to check with repository is busy with being a deployment)
>
> This is useful but maybe a more general capability to add to Archiva in a separate issue. I'd be happy to get a very basic stage/promotion mechanism in place for this project and do it very well (then worry about new things that can be done later). You could probably have a bit more detail on the implementation in that regard as it gets into some tricky areas, particularly considering multiple deployments, etc. I'd also look at building it up from pieces: so define how it works here, think about how it looks from the UI, but then when implementing get the low level merge operations working first at the API/testing level, then work up to the user interface and so on.
>
> Does that make sense?
>
> Cheers,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
>
>
>
>
Re: proposal for stage repository
Posted by Deng Ching <oc...@apache.org>.
Hi Eshan,
Thanks for updating the proposal! I also made some minor changes to it --
fixed the formatting and also some typos.
Btw, if you're having a hard time editing the wiki, there's a reference to
the Full Notation guide on the right hand side when you edit the page. It
contains the symbols/figures that you can use to format a wiki page :)
-Deng
On Thu, May 6, 2010 at 7:44 AM, Eshan Sudharaka <es...@gmail.com>wrote:
> On Wed, May 5, 2010 at 10:29 AM, Deng Ching <oc...@apache.org> wrote:
>
> > On Wed, May 5, 2010 at 8:23 AM, Eshan Sudharaka <esudharaka@gmail.com
> > >wrote:
> >
> > > On Tue, May 4, 2010 at 12:20 PM, Brett Porter <br...@apache.org>
> wrote:
> > >
> > > > On 01/05/2010, at 12:57 PM, Eshan Sudharaka wrote:
> > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/ARCHIVA/Staging+Repository+Merge
> > > > >
> > > > > It will be more useful for me to understand the missing parts and
> the
> > > > > conflicts by going through the comments.So all are warmly welcome
> to
> > > > share
> > > > > ideas to make that thing a success.
> > > >
> > > > Looking good.
> > > >
> > > > Here are some more comments:
> > > >
> > > > > I think in the stage repository we should limit the access. Nobody
> > > should
> > > > allow to download the artifacts in the staging repositories other
> than
> > > the
> > > > developers,QA people, archiva admin user ,and the the guy who have
> the
> > > > permission for the promotion.
> > > > >
> > > > > I think it is the repository manager's task to create the stage
> > > > repositories and attach it to the main repository that he want to add
> > the
> > > > staging functionality.
> > > >
> > > > I generally agree with this, but maybe it should be more general -
> > those
> > > > might be the defaults, but it's really a matter of specifying how the
> > > roles
> > > > and permissions relate and can be assigned. Does that make sense?
> > > >
> > >
> > > >>>> As i understood you mean that the permissions should be
> > > configurable for any use.is it ?
> > >
> >
> > I think what Brett meant here is not specifically categorizing between QA
> > and developers, but more of like a generic role similar to what we
> > currently
> > have -- Repository Manager and Repository Observer. It's possible that we
> > might not even need to add a new role for this and just add a set of new
> > permissions that can be assigned to the existing roles.
> >
> >
> > >
> > > >
> > > > This started to be covered in the next section, but that also talks
> > about
> > > > the behaviour - maybe it would be better to rephrase these as
> 'stories'
> > > for
> > > > users in certain roles (this will help break it up into tasks to
> > complete
> > > as
> > > > well).
> > > >
> > > > > If the artifact is an existing one(latest version) we need to
> provide
> > > > following options.
> > > >
> > > >
> > > > I'm not sure about these options. I think we can honour the current
> > > > repository configuration - that is either just let it replace, or
> block
> > > it
> > > > as not allowed to overwrite existing releases.
> > > >
> > > > > But if there are no significant changes in both artifacts then it
> is
> > > > better to remove the version 1.3 and add 1.4.
> > > >
> > > >
> > > > I don't think Archiva should get into this judgement call here - old
> > > > releases need to stay around (and the existing delete functionality
> is
> > > there
> > > > if there is a need to remove old things for some reason).
> > > >
> > >
> > > >>> As you have mentioned there is no point of replacing the
> artifacts
> > > for
> > > the new versions.(if we have version 1.2 it will be remain in the repo
> > > until
> > > we will do a re release of same 1.2) So i hope to add this replacing
> > option
> > > for only a re-release in the stage repository..
> > >
> > >
> > +1, I think you need update the proposal to reflect this instead of using
> > the 1.3 and 1.4 versions example :)
> >
> >
> > >
> > > >
> > > > BTW, will merging be meaningful for snapshot repositories?
> > > >
> > >
> > > >>>> as i understood for the snapshot merging is not necessary.But i
> > need
> > > to clarify it from you guyz.
> > >
> >
> > I don't think the repository merging is significant for snapshot
> > repositories..
> >
> >
> > >
> > > >
> > > > In the implementation, some of the above is covered and there is more
> > > like:
> > > >
> > > > > add the simultaneous deployment functionality for the stage
> > > > repositories.(here need to find a way to check with repository is
> busy
> > > with
> > > > being a deployment)
> > > >
> > > > This is useful but maybe a more general capability to add to Archiva
> in
> > a
> > > > separate issue. I'd be happy to get a very basic stage/promotion
> > > mechanism
> > > > in place for this project and do it very well (then worry about new
> > > things
> > > > that can be done later). You could probably have a bit more detail on
> > the
> > > > implementation in that regard as it gets into some tricky areas,
> > > > particularly considering multiple deployments, etc. I'd also look at
> > > > building it up from pieces: so define how it works here, think about
> > how
> > > it
> > > > looks from the UI, but then when implementing get the low level merge
> > > > operations working first at the API/testing level, then work up to
> the
> > > user
> > > > interface and so on.
> > > >
> > >
> > >
> > >
> > > > Does that make sense?
> > > >
> > > >>>>>> you mean that first we need to get the basic thing done and
> > then
> > > move for further enhancements.
> > >
> >
> > To help you get a better picture of what Brett meant above.. what we can
> > probably do is break down the implementation into smaller bits, maybe
> > something like this:
> > 1. repository merge
> > 2. web UI for merging repositories and for resolving conflicts during the
> > merge + integration with #1
> > 3. security changes
> >
> > For #1, I agree with what Dan said in his email to try to get the
> > repository
> > merge working first with the current repository manager role then apply
> the
> > necessary roles/permissions later on once you get that core functionality
> > working (this is #3 above). Also, the repository merge will definitely be
> > implemented as a separate component from the webapp that's why it was
> > broken
> > down into #1 and #2 above. This is where the tests come in. Since there
> is
> > no integration yet between the UI and the repository merge while you're
> > working on #1, you need to write tests for this in order to ensure that
> the
> > repository merge is working and that you've covered the different
> > scenarios.
> > Once you get #1 working, you can then start implementing the web UI for
> the
> > merging (this is #2) and start integrating this with the core repository
> > merging functionality that you did in #1. You would also need to write
> > Selenium tests in #2. After you've finished the integration, make the
> > necessary changes in the security component (for example, add a new role
> or
> > new permission for reading and writing to the staging repository, or
> adding
> > a restriction on who can merge repositories, etc.)
> >
> > Thanks,
> > Deng
> >
>
> >>>>
> thanks for the explanation.It gave me a good sense about the process.I
> have edited the proposal according to the ideas here.
>
>
>
>
> --
> P.A.Eshan Sudharaka
> Dept of Computer Science and Engineering
> University of Moratuwa
> Sri Lanka
>
Re: proposal for stage repository
Posted by Eshan Sudharaka <es...@gmail.com>.
On Wed, May 5, 2010 at 10:29 AM, Deng Ching <oc...@apache.org> wrote:
> On Wed, May 5, 2010 at 8:23 AM, Eshan Sudharaka <esudharaka@gmail.com
> >wrote:
>
> > On Tue, May 4, 2010 at 12:20 PM, Brett Porter <br...@apache.org> wrote:
> >
> > > On 01/05/2010, at 12:57 PM, Eshan Sudharaka wrote:
> > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/ARCHIVA/Staging+Repository+Merge
> > > >
> > > > It will be more useful for me to understand the missing parts and the
> > > > conflicts by going through the comments.So all are warmly welcome to
> > > share
> > > > ideas to make that thing a success.
> > >
> > > Looking good.
> > >
> > > Here are some more comments:
> > >
> > > > I think in the stage repository we should limit the access. Nobody
> > should
> > > allow to download the artifacts in the staging repositories other than
> > the
> > > developers,QA people, archiva admin user ,and the the guy who have the
> > > permission for the promotion.
> > > >
> > > > I think it is the repository manager's task to create the stage
> > > repositories and attach it to the main repository that he want to add
> the
> > > staging functionality.
> > >
> > > I generally agree with this, but maybe it should be more general -
> those
> > > might be the defaults, but it's really a matter of specifying how the
> > roles
> > > and permissions relate and can be assigned. Does that make sense?
> > >
> >
> > >>>> As i understood you mean that the permissions should be
> > configurable for any use.is it ?
> >
>
> I think what Brett meant here is not specifically categorizing between QA
> and developers, but more of like a generic role similar to what we
> currently
> have -- Repository Manager and Repository Observer. It's possible that we
> might not even need to add a new role for this and just add a set of new
> permissions that can be assigned to the existing roles.
>
>
> >
> > >
> > > This started to be covered in the next section, but that also talks
> about
> > > the behaviour - maybe it would be better to rephrase these as 'stories'
> > for
> > > users in certain roles (this will help break it up into tasks to
> complete
> > as
> > > well).
> > >
> > > > If the artifact is an existing one(latest version) we need to provide
> > > following options.
> > >
> > >
> > > I'm not sure about these options. I think we can honour the current
> > > repository configuration - that is either just let it replace, or block
> > it
> > > as not allowed to overwrite existing releases.
> > >
> > > > But if there are no significant changes in both artifacts then it is
> > > better to remove the version 1.3 and add 1.4.
> > >
> > >
> > > I don't think Archiva should get into this judgement call here - old
> > > releases need to stay around (and the existing delete functionality is
> > there
> > > if there is a need to remove old things for some reason).
> > >
> >
> > >>> As you have mentioned there is no point of replacing the artifacts
> > for
> > the new versions.(if we have version 1.2 it will be remain in the repo
> > until
> > we will do a re release of same 1.2) So i hope to add this replacing
> option
> > for only a re-release in the stage repository..
> >
> >
> +1, I think you need update the proposal to reflect this instead of using
> the 1.3 and 1.4 versions example :)
>
>
> >
> > >
> > > BTW, will merging be meaningful for snapshot repositories?
> > >
> >
> > >>>> as i understood for the snapshot merging is not necessary.But i
> need
> > to clarify it from you guyz.
> >
>
> I don't think the repository merging is significant for snapshot
> repositories..
>
>
> >
> > >
> > > In the implementation, some of the above is covered and there is more
> > like:
> > >
> > > > add the simultaneous deployment functionality for the stage
> > > repositories.(here need to find a way to check with repository is busy
> > with
> > > being a deployment)
> > >
> > > This is useful but maybe a more general capability to add to Archiva in
> a
> > > separate issue. I'd be happy to get a very basic stage/promotion
> > mechanism
> > > in place for this project and do it very well (then worry about new
> > things
> > > that can be done later). You could probably have a bit more detail on
> the
> > > implementation in that regard as it gets into some tricky areas,
> > > particularly considering multiple deployments, etc. I'd also look at
> > > building it up from pieces: so define how it works here, think about
> how
> > it
> > > looks from the UI, but then when implementing get the low level merge
> > > operations working first at the API/testing level, then work up to the
> > user
> > > interface and so on.
> > >
> >
> >
> >
> > > Does that make sense?
> > >
> > >>>>>> you mean that first we need to get the basic thing done and
> then
> > move for further enhancements.
> >
>
> To help you get a better picture of what Brett meant above.. what we can
> probably do is break down the implementation into smaller bits, maybe
> something like this:
> 1. repository merge
> 2. web UI for merging repositories and for resolving conflicts during the
> merge + integration with #1
> 3. security changes
>
> For #1, I agree with what Dan said in his email to try to get the
> repository
> merge working first with the current repository manager role then apply the
> necessary roles/permissions later on once you get that core functionality
> working (this is #3 above). Also, the repository merge will definitely be
> implemented as a separate component from the webapp that's why it was
> broken
> down into #1 and #2 above. This is where the tests come in. Since there is
> no integration yet between the UI and the repository merge while you're
> working on #1, you need to write tests for this in order to ensure that the
> repository merge is working and that you've covered the different
> scenarios.
> Once you get #1 working, you can then start implementing the web UI for the
> merging (this is #2) and start integrating this with the core repository
> merging functionality that you did in #1. You would also need to write
> Selenium tests in #2. After you've finished the integration, make the
> necessary changes in the security component (for example, add a new role or
> new permission for reading and writing to the staging repository, or adding
> a restriction on who can merge repositories, etc.)
>
> Thanks,
> Deng
>
>>>>
thanks for the explanation.It gave me a good sense about the process.I
have edited the proposal according to the ideas here.
--
P.A.Eshan Sudharaka
Dept of Computer Science and Engineering
University of Moratuwa
Sri Lanka
Re: proposal for stage repository
Posted by Deng Ching <oc...@apache.org>.
On Wed, May 5, 2010 at 8:23 AM, Eshan Sudharaka <es...@gmail.com>wrote:
> On Tue, May 4, 2010 at 12:20 PM, Brett Porter <br...@apache.org> wrote:
>
> > On 01/05/2010, at 12:57 PM, Eshan Sudharaka wrote:
> >
> > >
> >
> https://cwiki.apache.org/confluence/display/ARCHIVA/Staging+Repository+Merge
> > >
> > > It will be more useful for me to understand the missing parts and the
> > > conflicts by going through the comments.So all are warmly welcome to
> > share
> > > ideas to make that thing a success.
> >
> > Looking good.
> >
> > Here are some more comments:
> >
> > > I think in the stage repository we should limit the access. Nobody
> should
> > allow to download the artifacts in the staging repositories other than
> the
> > developers,QA people, archiva admin user ,and the the guy who have the
> > permission for the promotion.
> > >
> > > I think it is the repository manager's task to create the stage
> > repositories and attach it to the main repository that he want to add the
> > staging functionality.
> >
> > I generally agree with this, but maybe it should be more general - those
> > might be the defaults, but it's really a matter of specifying how the
> roles
> > and permissions relate and can be assigned. Does that make sense?
> >
>
> >>>> As i understood you mean that the permissions should be
> configurable for any use.is it ?
>
I think what Brett meant here is not specifically categorizing between QA
and developers, but more of like a generic role similar to what we currently
have -- Repository Manager and Repository Observer. It's possible that we
might not even need to add a new role for this and just add a set of new
permissions that can be assigned to the existing roles.
>
> >
> > This started to be covered in the next section, but that also talks about
> > the behaviour - maybe it would be better to rephrase these as 'stories'
> for
> > users in certain roles (this will help break it up into tasks to complete
> as
> > well).
> >
> > > If the artifact is an existing one(latest version) we need to provide
> > following options.
> >
> >
> > I'm not sure about these options. I think we can honour the current
> > repository configuration - that is either just let it replace, or block
> it
> > as not allowed to overwrite existing releases.
> >
> > > But if there are no significant changes in both artifacts then it is
> > better to remove the version 1.3 and add 1.4.
> >
> >
> > I don't think Archiva should get into this judgement call here - old
> > releases need to stay around (and the existing delete functionality is
> there
> > if there is a need to remove old things for some reason).
> >
>
> >>> As you have mentioned there is no point of replacing the artifacts
> for
> the new versions.(if we have version 1.2 it will be remain in the repo
> until
> we will do a re release of same 1.2) So i hope to add this replacing option
> for only a re-release in the stage repository..
>
>
+1, I think you need update the proposal to reflect this instead of using
the 1.3 and 1.4 versions example :)
>
> >
> > BTW, will merging be meaningful for snapshot repositories?
> >
>
> >>>> as i understood for the snapshot merging is not necessary.But i need
> to clarify it from you guyz.
>
I don't think the repository merging is significant for snapshot
repositories..
>
> >
> > In the implementation, some of the above is covered and there is more
> like:
> >
> > > add the simultaneous deployment functionality for the stage
> > repositories.(here need to find a way to check with repository is busy
> with
> > being a deployment)
> >
> > This is useful but maybe a more general capability to add to Archiva in a
> > separate issue. I'd be happy to get a very basic stage/promotion
> mechanism
> > in place for this project and do it very well (then worry about new
> things
> > that can be done later). You could probably have a bit more detail on the
> > implementation in that regard as it gets into some tricky areas,
> > particularly considering multiple deployments, etc. I'd also look at
> > building it up from pieces: so define how it works here, think about how
> it
> > looks from the UI, but then when implementing get the low level merge
> > operations working first at the API/testing level, then work up to the
> user
> > interface and so on.
> >
>
>
>
> > Does that make sense?
> >
> >>>>>> you mean that first we need to get the basic thing done and then
> move for further enhancements.
>
To help you get a better picture of what Brett meant above.. what we can
probably do is break down the implementation into smaller bits, maybe
something like this:
1. repository merge
2. web UI for merging repositories and for resolving conflicts during the
merge + integration with #1
3. security changes
For #1, I agree with what Dan said in his email to try to get the repository
merge working first with the current repository manager role then apply the
necessary roles/permissions later on once you get that core functionality
working (this is #3 above). Also, the repository merge will definitely be
implemented as a separate component from the webapp that's why it was broken
down into #1 and #2 above. This is where the tests come in. Since there is
no integration yet between the UI and the repository merge while you're
working on #1, you need to write tests for this in order to ensure that the
repository merge is working and that you've covered the different scenarios.
Once you get #1 working, you can then start implementing the web UI for the
merging (this is #2) and start integrating this with the core repository
merging functionality that you did in #1. You would also need to write
Selenium tests in #2. After you've finished the integration, make the
necessary changes in the security component (for example, add a new role or
new permission for reading and writing to the staging repository, or adding
a restriction on who can merge repositories, etc.)
Thanks,
Deng
Re: proposal for stage repository
Posted by Eshan Sudharaka <es...@gmail.com>.
On Tue, May 4, 2010 at 12:20 PM, Brett Porter <br...@apache.org> wrote:
> On 01/05/2010, at 12:57 PM, Eshan Sudharaka wrote:
>
> >
> https://cwiki.apache.org/confluence/display/ARCHIVA/Staging+Repository+Merge
> >
> > It will be more useful for me to understand the missing parts and the
> > conflicts by going through the comments.So all are warmly welcome to
> share
> > ideas to make that thing a success.
>
> Looking good.
>
> Here are some more comments:
>
> > I think in the stage repository we should limit the access. Nobody should
> allow to download the artifacts in the staging repositories other than the
> developers,QA people, archiva admin user ,and the the guy who have the
> permission for the promotion.
> >
> > I think it is the repository manager's task to create the stage
> repositories and attach it to the main repository that he want to add the
> staging functionality.
>
> I generally agree with this, but maybe it should be more general - those
> might be the defaults, but it's really a matter of specifying how the roles
> and permissions relate and can be assigned. Does that make sense?
>
>>>> As i understood you mean that the permissions should be
configurable for any use.is it ?
>
> This started to be covered in the next section, but that also talks about
> the behaviour - maybe it would be better to rephrase these as 'stories' for
> users in certain roles (this will help break it up into tasks to complete as
> well).
>
> > If the artifact is an existing one(latest version) we need to provide
> following options.
>
>
> I'm not sure about these options. I think we can honour the current
> repository configuration - that is either just let it replace, or block it
> as not allowed to overwrite existing releases.
>
> > But if there are no significant changes in both artifacts then it is
> better to remove the version 1.3 and add 1.4.
>
>
> I don't think Archiva should get into this judgement call here - old
> releases need to stay around (and the existing delete functionality is there
> if there is a need to remove old things for some reason).
>
>>> As you have mentioned there is no point of replacing the artifacts for
the new versions.(if we have version 1.2 it will be remain in the repo until
we will do a re release of same 1.2) So i hope to add this replacing option
for only a re-release in the stage repository..
>
> BTW, will merging be meaningful for snapshot repositories?
>
>>>> as i understood for the snapshot merging is not necessary.But i need
to clarify it from you guyz.
>
> In the implementation, some of the above is covered and there is more like:
>
> > add the simultaneous deployment functionality for the stage
> repositories.(here need to find a way to check with repository is busy with
> being a deployment)
>
> This is useful but maybe a more general capability to add to Archiva in a
> separate issue. I'd be happy to get a very basic stage/promotion mechanism
> in place for this project and do it very well (then worry about new things
> that can be done later). You could probably have a bit more detail on the
> implementation in that regard as it gets into some tricky areas,
> particularly considering multiple deployments, etc. I'd also look at
> building it up from pieces: so define how it works here, think about how it
> looks from the UI, but then when implementing get the low level merge
> operations working first at the API/testing level, then work up to the user
> interface and so on.
>
> Does that make sense?
>
>>>>>> you mean that first we need to get the basic thing done and then
move for further enhancements.
>
> 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
Re: proposal for stage repository
Posted by Brett Porter <br...@apache.org>.
On 01/05/2010, at 12:57 PM, Eshan Sudharaka wrote:
> https://cwiki.apache.org/confluence/display/ARCHIVA/Staging+Repository+Merge
>
> It will be more useful for me to understand the missing parts and the
> conflicts by going through the comments.So all are warmly welcome to share
> ideas to make that thing a success.
Looking good.
Here are some more comments:
> I think in the stage repository we should limit the access. Nobody should allow to download the artifacts in the staging repositories other than the developers,QA people, archiva admin user ,and the the guy who have the permission for the promotion.
>
> I think it is the repository manager's task to create the stage repositories and attach it to the main repository that he want to add the staging functionality.
I generally agree with this, but maybe it should be more general - those might be the defaults, but it's really a matter of specifying how the roles and permissions relate and can be assigned. Does that make sense?
This started to be covered in the next section, but that also talks about the behaviour - maybe it would be better to rephrase these as 'stories' for users in certain roles (this will help break it up into tasks to complete as well).
> If the artifact is an existing one(latest version) we need to provide following options.
I'm not sure about these options. I think we can honour the current repository configuration - that is either just let it replace, or block it as not allowed to overwrite existing releases.
> But if there are no significant changes in both artifacts then it is better to remove the version 1.3 and add 1.4.
I don't think Archiva should get into this judgement call here - old releases need to stay around (and the existing delete functionality is there if there is a need to remove old things for some reason).
BTW, will merging be meaningful for snapshot repositories?
In the implementation, some of the above is covered and there is more like:
> add the simultaneous deployment functionality for the stage repositories.(here need to find a way to check with repository is busy with being a deployment)
This is useful but maybe a more general capability to add to Archiva in a separate issue. I'd be happy to get a very basic stage/promotion mechanism in place for this project and do it very well (then worry about new things that can be done later). You could probably have a bit more detail on the implementation in that regard as it gets into some tricky areas, particularly considering multiple deployments, etc. I'd also look at building it up from pieces: so define how it works here, think about how it looks from the UI, but then when implementing get the low level merge operations working first at the API/testing level, then work up to the user interface and so on.
Does that make sense?
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/