On Wed, May 5, 2010 at 8:23 AM, Eshan Sudharaka <[email protected]>wrote:
> On Tue, May 4, 2010 at 12:20 PM, Brett Porter <[email protected]> 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
