You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@archiva.apache.org by Wendy Smoak <ws...@gmail.com> on 2010/04/02 22:47:34 UTC
Staging repositories (was: Re: GSoC projects?)
(I changed the subject line so it doesn't get lost in the generic discussion)
On Fri, Apr 2, 2010 at 4:15 PM, eshan sudharaka <es...@gmail.com> wrote:
> * Assign a Temporory reposotory for a group.(eg : com.MyTempRep.example)
How do you think this should happen? Currently an admin has to create
a repo and assign permissions before it can be used.
> * Only they are allowed to publish artifacts and the tempo rory repo is only
> open to them untill deploye the all artifacts to be tested.(not visible to
> the common repo with have tesed modules)
How would you determine that all the artifacts have been deployed?
> * once the temporory reposotory is closed it should me prevented from the
> developers being updating and it should be opened to QA people to
> testing(Same temporory repo will be used.only acces grants should be chaged
> and assing the acces for the QA group)
Archiva doesn't currently know anything about 'developers' vs. 'QA'.
It just has users with roles like repository manager or observer.
Is this something you want to introduce?
> * once testing is done > if it success then merge the temp repo to the
> common repo(where the tested modules are located)
> if it fails then manually removed from the repo.
IMO, this is the most important part (the promotion/merge step) and it
could be addressed separately from the roles/repo access part.
In fact I'd like to be able to merge any two repositories, separately
from any staging/promotion workflow. See
http://jira.codehaus.org/browse/MRM-980
> I dont understand how the audit log is linking with this project idea.could
> u please explain it?
The audit log needs to record all changes to the repositories.
who/what/where, etc. That would apply to these staging repos as well.
Unless it's already been changed, I remember the audit logging being a
rather complex event driven thing. Don't get too bogged down in it if
it looks scary, it probably needs to be reworked as a separate
project.
> and also are we need to wary about the changes that are done in the
> artifacts in temporary repo (by developers).I mean whether we should provide
> a facility like svn diff ?
Once an artifact is deployed, it should not change. (I believe
Archiva already prevents re-deploying a released [non-SNAPSHOT]
artifact.) So no, I don't think a diff utility is needed.
--
Wendy
Re: Staging repositories (was: Re: GSoC projects?)
Posted by Deng Ching <oc...@apache.org>.
On Mon, Apr 5, 2010 at 4:01 PM, Eshan Sudharaka <es...@gmail.com>wrote:
> On Mon, Apr 5, 2010 at 12:18 PM, Deng Ching <oc...@apache.org> wrote:
>
> > On Mon, Apr 5, 2010 at 8:55 AM, eshan sudharaka <esudharaka@gmail.com
> > >wrote:
> >
> > >
> > > As all of u guys mentioned a separate repository is a must for staging
> > > artifacts.
> > > Then all the registered archiva usrs have the access to that.
> > >
> > > In most of the companies projects are done by modular basis and those
> > > modules are assign to developers.So i thought that tech lead should
> > access
> > > archiva stage repository and then assign a project location for his
> > > group.(This location should be only access by only team members)
> > >
> > > once the development has done it is the tech lead's task to notify the
> > sys
> > > admin and ask the permision for merge the content in to common
> > repository.
> > >
> >
> > As Wendy pointed out in her previous email, Archiva currently only have 2
> > roles: a repository manager (read & write access to repo) and a
> repository
> > observer (read access only). Will you be introducing a new set of roles
> > and/or permissions for this?
> > > I guess that we can handle this through the permission
> levels.Hope
> > that we can change the access (for a repo) time to time...
> >
> > >
> > > * Here we need to search through the common repo for the projects
> > > which has the same name and give options to user to override them or
> > keep
> > > the older version on the repo.
> > >
> >
> > Sounds good :) How will these options be presented to the user?
> >
> >
>
>
> > > currently archiva has the search option for a particular
> repo.So
> > we can use this facility and just notyfy the user where a duplicate is
> > found.
> >
>
I think you can also use the MetadataResolver to check if the artifact
already exists in the repository.
> > >
> > > * question : can you explain me where these kind of overriding
> things
> > > are happening...is this due to merge same repo repeating ?
> > >
> >
> > The blocking of re-deployments for released artifacts happens in the
> > archiva-webdav module, particularly the ArchivaDavResourceFactory class.
> > But
> > given that this is different from a regular artifact deployment, I think
> it
> > should be put in a separate component.
> >
>
> > we can have a seperate component.I have a problem.Letz say we need a
> redeplyement what we have to do....do we need to delete the original copy
> and then deploye the latest one..??? and also still cannot understand what
> is the important of meta data update...
>
>
This is how artifact deployments currently work in Archiva:
1. artifact is deployed to Archiva repository
2. Archiva checks if the artifact is a released artifact and whether it
already exists in the repository
2.2. if it already exists, Archiva checks whether artifact redeployments
are allowed for the repository (this is configured in the Repository
Configuration via the Block re-deployment of Released Artifacts field)
- if it is allowed, then Archiva will replace/overwrite the
existing artifact with the new one
- if it is not allowed, then Archiva will return a 409 error
2.3. if the artifact does not exist in the repository, Archiva will put
the artifact in the repository
3. If the artifact is a SNAPSHOT (not a released version), Archiva will put
the artifact in the repository
In the case of repository merging, the artifacts that already exist in the
repository should be identified first and presented to the user (as you've
already mentioned above). Then the user can decide whether to overwrite the
existing artifacts or skip them, and Archiva will merge the repositories
with respect to what the user has decided.
> (are we going to merage only the changes in to the common repo?? i mean for
> a redployement..)
> and when we deploye a fresh artifacts what is the point of updating meta
> data...um confusing here..
>
>
It is necessary to update the metadata file for new versions since that is
what Maven uses for resolving artifacts in a remote repository :) Archiva
already has a utility for merging and creating metadata files. You can take
a look at MetadataTools and MetadataUpdaterConsumer classes on how to merge
and fix metadata.
> >
> >
> > >
> > > * It is the tech lead task to release the project for the QA
> ppl.(Since
> > he
> > > is the current admin for the project on the staging repo.Developers
> > access
> > > should be restricted before the QA release)
> > >
> > > Eshan.
> > > thank you.
> > >
> >
> > Thanks,
> > Deng
> >
> >
> > >
> > > Deng Ching-2 wrote:
> > > >
> > > > I agree with Dan. I think it should be kept as simple as possible..
> :)
> > > >
> > > > In addition to what Dan listed below, I think the following should be
> > > > addressed in the design:
> > > > - creation of the staging repository (should it be distinguished and
> > how
> > > > will it be distinguished it from a regular repository?)
> > > > - merging of the staged artifacts to the final repository
> > > > - deletion of the staging repository (should Archiva do this after
> the
> > > > merging? or should the user manually delete it?)
> > > > - security (who will be able to promote artifacts? will the granting
> of
> > > > access to the staging repo be just the same as what is currently
> > > > implemented? or will batch assignment of permissions to a group/set
> of
> > > > users
> > > > be supported?)
> > > >
> > > > Thanks,
> > > > Deng
> > > >
> > > > On Sat, Apr 3, 2010 at 5:25 AM, Dan Tran <da...@gmail.com> wrote:
> > > >
> > > >> From a build admin perspective, this what I would like to have:
> > > >>
> > > >>
> > > >> 1. Create a permanent staging repository on archiva where I can
> > > >> release/deploy all my projects one at the time.
> > > >>
> > > >> I can have multiple staging repos so that I can release multiple
> > > >> project at the same time
> > > >>
> > > >> 2. Once the artifacts at a staging repos, I'd like it to merge the
> > > >> staging repo into the official release repo. Finally wipe out the
> > > >> staging repo's content
> > > >>
> > > >> I think Archiva should keep the requiment as simple as these.
> > > >>
> > > >> Thanks
> > > >>
> > > >> -Dan
> > > >>
> > > >> On Fri, Apr 2, 2010 at 1:47 PM, Wendy Smoak <ws...@gmail.com>
> wrote:
> > > >> > (I changed the subject line so it doesn't get lost in the generic
> > > >> discussion)
> > > >> >
> > > >> > On Fri, Apr 2, 2010 at 4:15 PM, eshan sudharaka <
> > esudharaka@gmail.com
> > > >
> > > >> wrote:
> > > >> >
> > > >> >> * Assign a Temporory reposotory for a group.(eg :
> > > >> com.MyTempRep.example)
> > > >> >
> > > >> > How do you think this should happen? Currently an admin has to
> > create
> > > >> > a repo and assign permissions before it can be used.
> > > >> >
> > > >> >> * Only they are allowed to publish artifacts and the tempo rory
> > repo
> > > >> is
> > > >> only
> > > >> >> open to them untill deploye the all artifacts to be
> > > tested.(not
> > > >> visible to
> > > >> >> the common repo with have tesed modules)
> > > >> >
> > > >> > How would you determine that all the artifacts have been deployed?
> > > >> >
> > > >> >> * once the temporory reposotory is closed it should me prevented
> > > from
> > > >> the
> > > >> >> developers being updating and it should be opened to QA people to
> > > >> >> testing(Same temporory repo will be used.only acces grants should
> > be
> > > >> chaged
> > > >> >> and assing the acces for the QA group)
> > > >> >
> > > >> > Archiva doesn't currently know anything about 'developers' vs.
> 'QA'.
> > > >> > It just has users with roles like repository manager or observer.
> > > >> >
> > > >> > Is this something you want to introduce?
> > > >> >
> > > >> >> * once testing is done > if it success then merge the temp repo
> to
> > > the
> > > >> >> common repo(where the tested modules are located)
> > > >> >> if it fails then manually removed from the repo.
> > > >> >
> > > >> > IMO, this is the most important part (the promotion/merge step)
> and
> > it
> > > >> > could be addressed separately from the roles/repo access part.
> > > >> >
> > > >> > In fact I'd like to be able to merge any two repositories,
> > separately
> > > >> > from any staging/promotion workflow. See
> > > >> > http://jira.codehaus.org/browse/MRM-980
> > > >> >
> > > >> >> I dont understand how the audit log is linking with this project
> > > >> idea.could
> > > >> >> u please explain it?
> > > >> >
> > > >> > The audit log needs to record all changes to the repositories.
> > > >> > who/what/where, etc. That would apply to these staging repos as
> > well.
> > > >> >
> > > >> > Unless it's already been changed, I remember the audit logging
> being
> > a
> > > >> > rather complex event driven thing. Don't get too bogged down in
> it
> > if
> > > >> > it looks scary, it probably needs to be reworked as a separate
> > > >> > project.
> > > >> >
> > > >> >> and also are we need to wary about the changes that are done in
> the
> > > >> >> artifacts in temporary repo (by developers).I mean whether we
> > should
> > > >> provide
> > > >> >> a facility like svn diff ?
> > > >> >
> > > >> > Once an artifact is deployed, it should not change. (I believe
> > > >> > Archiva already prevents re-deploying a released [non-SNAPSHOT]
> > > >> > artifact.) So no, I don't think a diff utility is needed.
> > > >> >
> > > >> > --
> > > >> > Wendy
> > > >> >
> > > >>
> > > >
> > > >
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://old.nabble.com/Staging-repositories-%28was%3A-Re%3A-GSoC-projects-%29-tp28122839p28133873.html
> > > Sent from the archiva-dev mailing list archive at Nabble.com.
> > >
> > >
> >
>
>
>
> --
> P.A.Eshan Sudharaka
> Dept of Computer Science and Engineering
> University of Moratuwa
> Sri Lanka
>
Re: Staging repositories (was: Re: GSoC projects?)
Posted by Eshan Sudharaka <es...@gmail.com>.
On Mon, Apr 5, 2010 at 12:18 PM, Deng Ching <oc...@apache.org> wrote:
> On Mon, Apr 5, 2010 at 8:55 AM, eshan sudharaka <esudharaka@gmail.com
> >wrote:
>
> >
> > As all of u guys mentioned a separate repository is a must for staging
> > artifacts.
> > Then all the registered archiva usrs have the access to that.
> >
> > In most of the companies projects are done by modular basis and those
> > modules are assign to developers.So i thought that tech lead should
> access
> > archiva stage repository and then assign a project location for his
> > group.(This location should be only access by only team members)
> >
> > once the development has done it is the tech lead's task to notify the
> sys
> > admin and ask the permision for merge the content in to common
> repository.
> >
>
> As Wendy pointed out in her previous email, Archiva currently only have 2
> roles: a repository manager (read & write access to repo) and a repository
> observer (read access only). Will you be introducing a new set of roles
> and/or permissions for this?
> > I guess that we can handle this through the permission levels.Hope
> that we can change the access (for a repo) time to time...
>
> >
> > * Here we need to search through the common repo for the projects
> > which has the same name and give options to user to override them or
> keep
> > the older version on the repo.
> >
>
> Sounds good :) How will these options be presented to the user?
>
>
> > currently archiva has the search option for a particular repo.So
> we can use this facility and just notyfy the user where a duplicate is
> found.
>
> >
> > * question : can you explain me where these kind of overriding things
> > are happening...is this due to merge same repo repeating ?
> >
>
> The blocking of re-deployments for released artifacts happens in the
> archiva-webdav module, particularly the ArchivaDavResourceFactory class.
> But
> given that this is different from a regular artifact deployment, I think it
> should be put in a separate component.
>
> we can have a seperate component.I have a problem.Letz say we need a
redeplyement what we have to do....do we need to delete the original copy
and then deploye the latest one..??? and also still cannot understand what
is the important of meta data update...
(are we going to merage only the changes in to the common repo?? i mean for
a redployement..)
and when we deploye a fresh artifacts what is the point of updating meta
data...um confusing here..
>
>
> >
> > * It is the tech lead task to release the project for the QA ppl.(Since
> he
> > is the current admin for the project on the staging repo.Developers
> access
> > should be restricted before the QA release)
> >
> > Eshan.
> > thank you.
> >
>
> Thanks,
> Deng
>
>
> >
> > Deng Ching-2 wrote:
> > >
> > > I agree with Dan. I think it should be kept as simple as possible.. :)
> > >
> > > In addition to what Dan listed below, I think the following should be
> > > addressed in the design:
> > > - creation of the staging repository (should it be distinguished and
> how
> > > will it be distinguished it from a regular repository?)
> > > - merging of the staged artifacts to the final repository
> > > - deletion of the staging repository (should Archiva do this after the
> > > merging? or should the user manually delete it?)
> > > - security (who will be able to promote artifacts? will the granting of
> > > access to the staging repo be just the same as what is currently
> > > implemented? or will batch assignment of permissions to a group/set of
> > > users
> > > be supported?)
> > >
> > > Thanks,
> > > Deng
> > >
> > > On Sat, Apr 3, 2010 at 5:25 AM, Dan Tran <da...@gmail.com> wrote:
> > >
> > >> From a build admin perspective, this what I would like to have:
> > >>
> > >>
> > >> 1. Create a permanent staging repository on archiva where I can
> > >> release/deploy all my projects one at the time.
> > >>
> > >> I can have multiple staging repos so that I can release multiple
> > >> project at the same time
> > >>
> > >> 2. Once the artifacts at a staging repos, I'd like it to merge the
> > >> staging repo into the official release repo. Finally wipe out the
> > >> staging repo's content
> > >>
> > >> I think Archiva should keep the requiment as simple as these.
> > >>
> > >> Thanks
> > >>
> > >> -Dan
> > >>
> > >> On Fri, Apr 2, 2010 at 1:47 PM, Wendy Smoak <ws...@gmail.com> wrote:
> > >> > (I changed the subject line so it doesn't get lost in the generic
> > >> discussion)
> > >> >
> > >> > On Fri, Apr 2, 2010 at 4:15 PM, eshan sudharaka <
> esudharaka@gmail.com
> > >
> > >> wrote:
> > >> >
> > >> >> * Assign a Temporory reposotory for a group.(eg :
> > >> com.MyTempRep.example)
> > >> >
> > >> > How do you think this should happen? Currently an admin has to
> create
> > >> > a repo and assign permissions before it can be used.
> > >> >
> > >> >> * Only they are allowed to publish artifacts and the tempo rory
> repo
> > >> is
> > >> only
> > >> >> open to them untill deploye the all artifacts to be
> > tested.(not
> > >> visible to
> > >> >> the common repo with have tesed modules)
> > >> >
> > >> > How would you determine that all the artifacts have been deployed?
> > >> >
> > >> >> * once the temporory reposotory is closed it should me prevented
> > from
> > >> the
> > >> >> developers being updating and it should be opened to QA people to
> > >> >> testing(Same temporory repo will be used.only acces grants should
> be
> > >> chaged
> > >> >> and assing the acces for the QA group)
> > >> >
> > >> > Archiva doesn't currently know anything about 'developers' vs. 'QA'.
> > >> > It just has users with roles like repository manager or observer.
> > >> >
> > >> > Is this something you want to introduce?
> > >> >
> > >> >> * once testing is done > if it success then merge the temp repo to
> > the
> > >> >> common repo(where the tested modules are located)
> > >> >> if it fails then manually removed from the repo.
> > >> >
> > >> > IMO, this is the most important part (the promotion/merge step) and
> it
> > >> > could be addressed separately from the roles/repo access part.
> > >> >
> > >> > In fact I'd like to be able to merge any two repositories,
> separately
> > >> > from any staging/promotion workflow. See
> > >> > http://jira.codehaus.org/browse/MRM-980
> > >> >
> > >> >> I dont understand how the audit log is linking with this project
> > >> idea.could
> > >> >> u please explain it?
> > >> >
> > >> > The audit log needs to record all changes to the repositories.
> > >> > who/what/where, etc. That would apply to these staging repos as
> well.
> > >> >
> > >> > Unless it's already been changed, I remember the audit logging being
> a
> > >> > rather complex event driven thing. Don't get too bogged down in it
> if
> > >> > it looks scary, it probably needs to be reworked as a separate
> > >> > project.
> > >> >
> > >> >> and also are we need to wary about the changes that are done in the
> > >> >> artifacts in temporary repo (by developers).I mean whether we
> should
> > >> provide
> > >> >> a facility like svn diff ?
> > >> >
> > >> > Once an artifact is deployed, it should not change. (I believe
> > >> > Archiva already prevents re-deploying a released [non-SNAPSHOT]
> > >> > artifact.) So no, I don't think a diff utility is needed.
> > >> >
> > >> > --
> > >> > Wendy
> > >> >
> > >>
> > >
> > >
> >
> > --
> > View this message in context:
> >
> http://old.nabble.com/Staging-repositories-%28was%3A-Re%3A-GSoC-projects-%29-tp28122839p28133873.html
> > Sent from the archiva-dev mailing list archive at Nabble.com.
> >
> >
>
--
P.A.Eshan Sudharaka
Dept of Computer Science and Engineering
University of Moratuwa
Sri Lanka
Re: Staging repositories (was: Re: GSoC projects?)
Posted by Deng Ching <oc...@apache.org>.
On Mon, Apr 5, 2010 at 8:55 AM, eshan sudharaka <es...@gmail.com>wrote:
>
> As all of u guys mentioned a separate repository is a must for staging
> artifacts.
> Then all the registered archiva usrs have the access to that.
>
> In most of the companies projects are done by modular basis and those
> modules are assign to developers.So i thought that tech lead should access
> archiva stage repository and then assign a project location for his
> group.(This location should be only access by only team members)
>
> once the development has done it is the tech lead's task to notify the sys
> admin and ask the permision for merge the content in to common repository.
>
As Wendy pointed out in her previous email, Archiva currently only have 2
roles: a repository manager (read & write access to repo) and a repository
observer (read access only). Will you be introducing a new set of roles
and/or permissions for this?
>
> * Here we need to search through the common repo for the projects
> which has the same name and give options to user to override them or keep
> the older version on the repo.
>
Sounds good :) How will these options be presented to the user?
>
> * question : can you explain me where these kind of overriding things
> are happening...is this due to merge same repo repeating ?
>
The blocking of re-deployments for released artifacts happens in the
archiva-webdav module, particularly the ArchivaDavResourceFactory class. But
given that this is different from a regular artifact deployment, I think it
should be put in a separate component.
>
> * It is the tech lead task to release the project for the QA ppl.(Since he
> is the current admin for the project on the staging repo.Developers access
> should be restricted before the QA release)
>
> Eshan.
> thank you.
>
Thanks,
Deng
>
> Deng Ching-2 wrote:
> >
> > I agree with Dan. I think it should be kept as simple as possible.. :)
> >
> > In addition to what Dan listed below, I think the following should be
> > addressed in the design:
> > - creation of the staging repository (should it be distinguished and how
> > will it be distinguished it from a regular repository?)
> > - merging of the staged artifacts to the final repository
> > - deletion of the staging repository (should Archiva do this after the
> > merging? or should the user manually delete it?)
> > - security (who will be able to promote artifacts? will the granting of
> > access to the staging repo be just the same as what is currently
> > implemented? or will batch assignment of permissions to a group/set of
> > users
> > be supported?)
> >
> > Thanks,
> > Deng
> >
> > On Sat, Apr 3, 2010 at 5:25 AM, Dan Tran <da...@gmail.com> wrote:
> >
> >> From a build admin perspective, this what I would like to have:
> >>
> >>
> >> 1. Create a permanent staging repository on archiva where I can
> >> release/deploy all my projects one at the time.
> >>
> >> I can have multiple staging repos so that I can release multiple
> >> project at the same time
> >>
> >> 2. Once the artifacts at a staging repos, I'd like it to merge the
> >> staging repo into the official release repo. Finally wipe out the
> >> staging repo's content
> >>
> >> I think Archiva should keep the requiment as simple as these.
> >>
> >> Thanks
> >>
> >> -Dan
> >>
> >> On Fri, Apr 2, 2010 at 1:47 PM, Wendy Smoak <ws...@gmail.com> wrote:
> >> > (I changed the subject line so it doesn't get lost in the generic
> >> discussion)
> >> >
> >> > On Fri, Apr 2, 2010 at 4:15 PM, eshan sudharaka <esudharaka@gmail.com
> >
> >> wrote:
> >> >
> >> >> * Assign a Temporory reposotory for a group.(eg :
> >> com.MyTempRep.example)
> >> >
> >> > How do you think this should happen? Currently an admin has to create
> >> > a repo and assign permissions before it can be used.
> >> >
> >> >> * Only they are allowed to publish artifacts and the tempo rory repo
> >> is
> >> only
> >> >> open to them untill deploye the all artifacts to be
> tested.(not
> >> visible to
> >> >> the common repo with have tesed modules)
> >> >
> >> > How would you determine that all the artifacts have been deployed?
> >> >
> >> >> * once the temporory reposotory is closed it should me prevented
> from
> >> the
> >> >> developers being updating and it should be opened to QA people to
> >> >> testing(Same temporory repo will be used.only acces grants should be
> >> chaged
> >> >> and assing the acces for the QA group)
> >> >
> >> > Archiva doesn't currently know anything about 'developers' vs. 'QA'.
> >> > It just has users with roles like repository manager or observer.
> >> >
> >> > Is this something you want to introduce?
> >> >
> >> >> * once testing is done > if it success then merge the temp repo to
> the
> >> >> common repo(where the tested modules are located)
> >> >> if it fails then manually removed from the repo.
> >> >
> >> > IMO, this is the most important part (the promotion/merge step) and it
> >> > could be addressed separately from the roles/repo access part.
> >> >
> >> > In fact I'd like to be able to merge any two repositories, separately
> >> > from any staging/promotion workflow. See
> >> > http://jira.codehaus.org/browse/MRM-980
> >> >
> >> >> I dont understand how the audit log is linking with this project
> >> idea.could
> >> >> u please explain it?
> >> >
> >> > The audit log needs to record all changes to the repositories.
> >> > who/what/where, etc. That would apply to these staging repos as well.
> >> >
> >> > Unless it's already been changed, I remember the audit logging being a
> >> > rather complex event driven thing. Don't get too bogged down in it if
> >> > it looks scary, it probably needs to be reworked as a separate
> >> > project.
> >> >
> >> >> and also are we need to wary about the changes that are done in the
> >> >> artifacts in temporary repo (by developers).I mean whether we should
> >> provide
> >> >> a facility like svn diff ?
> >> >
> >> > Once an artifact is deployed, it should not change. (I believe
> >> > Archiva already prevents re-deploying a released [non-SNAPSHOT]
> >> > artifact.) So no, I don't think a diff utility is needed.
> >> >
> >> > --
> >> > Wendy
> >> >
> >>
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/Staging-repositories-%28was%3A-Re%3A-GSoC-projects-%29-tp28122839p28133873.html
> Sent from the archiva-dev mailing list archive at Nabble.com.
>
>
Re: Staging repositories (was: Re: GSoC projects?)
Posted by eshan sudharaka <es...@gmail.com>.
As all of u guys mentioned a separate repository is a must for staging
artifacts.
Then all the registered archiva usrs have the access to that.
In most of the companies projects are done by modular basis and those
modules are assign to developers.So i thought that tech lead should access
archiva stage repository and then assign a project location for his
group.(This location should be only access by only team members)
once the development has done it is the tech lead's task to notify the sys
admin and ask the permision for merge the content in to common repository.
* Here we need to search through the common repo for the projects
which has the same name and give options to user to override them or keep
the older version on the repo.
* question : can you explain me where these kind of overriding things
are happening...is this due to merge same repo repeating ?
* It is the tech lead task to release the project for the QA ppl.(Since he
is the current admin for the project on the staging repo.Developers access
should be restricted before the QA release)
Eshan.
thank you.
Deng Ching-2 wrote:
>
> I agree with Dan. I think it should be kept as simple as possible.. :)
>
> In addition to what Dan listed below, I think the following should be
> addressed in the design:
> - creation of the staging repository (should it be distinguished and how
> will it be distinguished it from a regular repository?)
> - merging of the staged artifacts to the final repository
> - deletion of the staging repository (should Archiva do this after the
> merging? or should the user manually delete it?)
> - security (who will be able to promote artifacts? will the granting of
> access to the staging repo be just the same as what is currently
> implemented? or will batch assignment of permissions to a group/set of
> users
> be supported?)
>
> Thanks,
> Deng
>
> On Sat, Apr 3, 2010 at 5:25 AM, Dan Tran <da...@gmail.com> wrote:
>
>> From a build admin perspective, this what I would like to have:
>>
>>
>> 1. Create a permanent staging repository on archiva where I can
>> release/deploy all my projects one at the time.
>>
>> I can have multiple staging repos so that I can release multiple
>> project at the same time
>>
>> 2. Once the artifacts at a staging repos, I'd like it to merge the
>> staging repo into the official release repo. Finally wipe out the
>> staging repo's content
>>
>> I think Archiva should keep the requiment as simple as these.
>>
>> Thanks
>>
>> -Dan
>>
>> On Fri, Apr 2, 2010 at 1:47 PM, Wendy Smoak <ws...@gmail.com> wrote:
>> > (I changed the subject line so it doesn't get lost in the generic
>> discussion)
>> >
>> > On Fri, Apr 2, 2010 at 4:15 PM, eshan sudharaka <es...@gmail.com>
>> wrote:
>> >
>> >> * Assign a Temporory reposotory for a group.(eg :
>> com.MyTempRep.example)
>> >
>> > How do you think this should happen? Currently an admin has to create
>> > a repo and assign permissions before it can be used.
>> >
>> >> * Only they are allowed to publish artifacts and the tempo rory repo
>> is
>> only
>> >> open to them untill deploye the all artifacts to be tested.(not
>> visible to
>> >> the common repo with have tesed modules)
>> >
>> > How would you determine that all the artifacts have been deployed?
>> >
>> >> * once the temporory reposotory is closed it should me prevented from
>> the
>> >> developers being updating and it should be opened to QA people to
>> >> testing(Same temporory repo will be used.only acces grants should be
>> chaged
>> >> and assing the acces for the QA group)
>> >
>> > Archiva doesn't currently know anything about 'developers' vs. 'QA'.
>> > It just has users with roles like repository manager or observer.
>> >
>> > Is this something you want to introduce?
>> >
>> >> * once testing is done > if it success then merge the temp repo to the
>> >> common repo(where the tested modules are located)
>> >> if it fails then manually removed from the repo.
>> >
>> > IMO, this is the most important part (the promotion/merge step) and it
>> > could be addressed separately from the roles/repo access part.
>> >
>> > In fact I'd like to be able to merge any two repositories, separately
>> > from any staging/promotion workflow. See
>> > http://jira.codehaus.org/browse/MRM-980
>> >
>> >> I dont understand how the audit log is linking with this project
>> idea.could
>> >> u please explain it?
>> >
>> > The audit log needs to record all changes to the repositories.
>> > who/what/where, etc. That would apply to these staging repos as well.
>> >
>> > Unless it's already been changed, I remember the audit logging being a
>> > rather complex event driven thing. Don't get too bogged down in it if
>> > it looks scary, it probably needs to be reworked as a separate
>> > project.
>> >
>> >> and also are we need to wary about the changes that are done in the
>> >> artifacts in temporary repo (by developers).I mean whether we should
>> provide
>> >> a facility like svn diff ?
>> >
>> > Once an artifact is deployed, it should not change. (I believe
>> > Archiva already prevents re-deploying a released [non-SNAPSHOT]
>> > artifact.) So no, I don't think a diff utility is needed.
>> >
>> > --
>> > Wendy
>> >
>>
>
>
--
View this message in context: http://old.nabble.com/Staging-repositories-%28was%3A-Re%3A-GSoC-projects-%29-tp28122839p28133873.html
Sent from the archiva-dev mailing list archive at Nabble.com.
Re: Staging repositories (was: Re: GSoC projects?)
Posted by Dan Tran <da...@gmail.com>.
- Creating staging repo is same as a normal hosted repo. So repo admin will do.
- Ability to merge a repo to another repo. Again repo admin will do
- Finally, ability to clear out the entire repo should be repo admin as well.
However this feature is dangerous since user can shoot their own foot
-Dan
On Fri, Apr 2, 2010 at 7:25 PM, Deng Ching <oc...@apache.org> wrote:
> I agree with Dan. I think it should be kept as simple as possible.. :)
>
> In addition to what Dan listed below, I think the following should be
> addressed in the design:
> - creation of the staging repository (should it be distinguished and how
> will it be distinguished it from a regular repository?)
> - merging of the staged artifacts to the final repository
> - deletion of the staging repository (should Archiva do this after the
> merging? or should the user manually delete it?)
> - security (who will be able to promote artifacts? will the granting of
> access to the staging repo be just the same as what is currently
> implemented? or will batch assignment of permissions to a group/set of users
> be supported?)
>
> Thanks,
> Deng
>
> On Sat, Apr 3, 2010 at 5:25 AM, Dan Tran <da...@gmail.com> wrote:
>
>> From a build admin perspective, this what I would like to have:
>>
>>
>> 1. Create a permanent staging repository on archiva where I can
>> release/deploy all my projects one at the time.
>>
>> I can have multiple staging repos so that I can release multiple
>> project at the same time
>>
>> 2. Once the artifacts at a staging repos, I'd like it to merge the
>> staging repo into the official release repo. Finally wipe out the
>> staging repo's content
>>
>> I think Archiva should keep the requiment as simple as these.
>>
>> Thanks
>>
>> -Dan
>>
>> On Fri, Apr 2, 2010 at 1:47 PM, Wendy Smoak <ws...@gmail.com> wrote:
>> > (I changed the subject line so it doesn't get lost in the generic
>> discussion)
>> >
>> > On Fri, Apr 2, 2010 at 4:15 PM, eshan sudharaka <es...@gmail.com>
>> wrote:
>> >
>> >> * Assign a Temporory reposotory for a group.(eg : com.MyTempRep.example)
>> >
>> > How do you think this should happen? Currently an admin has to create
>> > a repo and assign permissions before it can be used.
>> >
>> >> * Only they are allowed to publish artifacts and the tempo rory repo is
>> only
>> >> open to them untill deploye the all artifacts to be tested.(not
>> visible to
>> >> the common repo with have tesed modules)
>> >
>> > How would you determine that all the artifacts have been deployed?
>> >
>> >> * once the temporory reposotory is closed it should me prevented from
>> the
>> >> developers being updating and it should be opened to QA people to
>> >> testing(Same temporory repo will be used.only acces grants should be
>> chaged
>> >> and assing the acces for the QA group)
>> >
>> > Archiva doesn't currently know anything about 'developers' vs. 'QA'.
>> > It just has users with roles like repository manager or observer.
>> >
>> > Is this something you want to introduce?
>> >
>> >> * once testing is done > if it success then merge the temp repo to the
>> >> common repo(where the tested modules are located)
>> >> if it fails then manually removed from the repo.
>> >
>> > IMO, this is the most important part (the promotion/merge step) and it
>> > could be addressed separately from the roles/repo access part.
>> >
>> > In fact I'd like to be able to merge any two repositories, separately
>> > from any staging/promotion workflow. See
>> > http://jira.codehaus.org/browse/MRM-980
>> >
>> >> I dont understand how the audit log is linking with this project
>> idea.could
>> >> u please explain it?
>> >
>> > The audit log needs to record all changes to the repositories.
>> > who/what/where, etc. That would apply to these staging repos as well.
>> >
>> > Unless it's already been changed, I remember the audit logging being a
>> > rather complex event driven thing. Don't get too bogged down in it if
>> > it looks scary, it probably needs to be reworked as a separate
>> > project.
>> >
>> >> and also are we need to wary about the changes that are done in the
>> >> artifacts in temporary repo (by developers).I mean whether we should
>> provide
>> >> a facility like svn diff ?
>> >
>> > Once an artifact is deployed, it should not change. (I believe
>> > Archiva already prevents re-deploying a released [non-SNAPSHOT]
>> > artifact.) So no, I don't think a diff utility is needed.
>> >
>> > --
>> > Wendy
>> >
>>
>
Re: Staging repositories (was: Re: GSoC projects?)
Posted by Deng Ching <oc...@apache.org>.
I agree with Dan. I think it should be kept as simple as possible.. :)
In addition to what Dan listed below, I think the following should be
addressed in the design:
- creation of the staging repository (should it be distinguished and how
will it be distinguished it from a regular repository?)
- merging of the staged artifacts to the final repository
- deletion of the staging repository (should Archiva do this after the
merging? or should the user manually delete it?)
- security (who will be able to promote artifacts? will the granting of
access to the staging repo be just the same as what is currently
implemented? or will batch assignment of permissions to a group/set of users
be supported?)
Thanks,
Deng
On Sat, Apr 3, 2010 at 5:25 AM, Dan Tran <da...@gmail.com> wrote:
> From a build admin perspective, this what I would like to have:
>
>
> 1. Create a permanent staging repository on archiva where I can
> release/deploy all my projects one at the time.
>
> I can have multiple staging repos so that I can release multiple
> project at the same time
>
> 2. Once the artifacts at a staging repos, I'd like it to merge the
> staging repo into the official release repo. Finally wipe out the
> staging repo's content
>
> I think Archiva should keep the requiment as simple as these.
>
> Thanks
>
> -Dan
>
> On Fri, Apr 2, 2010 at 1:47 PM, Wendy Smoak <ws...@gmail.com> wrote:
> > (I changed the subject line so it doesn't get lost in the generic
> discussion)
> >
> > On Fri, Apr 2, 2010 at 4:15 PM, eshan sudharaka <es...@gmail.com>
> wrote:
> >
> >> * Assign a Temporory reposotory for a group.(eg : com.MyTempRep.example)
> >
> > How do you think this should happen? Currently an admin has to create
> > a repo and assign permissions before it can be used.
> >
> >> * Only they are allowed to publish artifacts and the tempo rory repo is
> only
> >> open to them untill deploye the all artifacts to be tested.(not
> visible to
> >> the common repo with have tesed modules)
> >
> > How would you determine that all the artifacts have been deployed?
> >
> >> * once the temporory reposotory is closed it should me prevented from
> the
> >> developers being updating and it should be opened to QA people to
> >> testing(Same temporory repo will be used.only acces grants should be
> chaged
> >> and assing the acces for the QA group)
> >
> > Archiva doesn't currently know anything about 'developers' vs. 'QA'.
> > It just has users with roles like repository manager or observer.
> >
> > Is this something you want to introduce?
> >
> >> * once testing is done > if it success then merge the temp repo to the
> >> common repo(where the tested modules are located)
> >> if it fails then manually removed from the repo.
> >
> > IMO, this is the most important part (the promotion/merge step) and it
> > could be addressed separately from the roles/repo access part.
> >
> > In fact I'd like to be able to merge any two repositories, separately
> > from any staging/promotion workflow. See
> > http://jira.codehaus.org/browse/MRM-980
> >
> >> I dont understand how the audit log is linking with this project
> idea.could
> >> u please explain it?
> >
> > The audit log needs to record all changes to the repositories.
> > who/what/where, etc. That would apply to these staging repos as well.
> >
> > Unless it's already been changed, I remember the audit logging being a
> > rather complex event driven thing. Don't get too bogged down in it if
> > it looks scary, it probably needs to be reworked as a separate
> > project.
> >
> >> and also are we need to wary about the changes that are done in the
> >> artifacts in temporary repo (by developers).I mean whether we should
> provide
> >> a facility like svn diff ?
> >
> > Once an artifact is deployed, it should not change. (I believe
> > Archiva already prevents re-deploying a released [non-SNAPSHOT]
> > artifact.) So no, I don't think a diff utility is needed.
> >
> > --
> > Wendy
> >
>
Re: Staging repositories (was: Re: GSoC projects?)
Posted by Deng Ching <oc...@apache.org>.
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 <es...@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 <br...@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
>
Re: Staging repositories (was: Re: GSoC projects?)
Posted by Eshan Sudharaka <es...@gmail.com>.
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 <br...@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>.
> 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
Re: Staging repositories (was: Re: GSoC projects?)
Posted by Brett Porter <br...@apache.org>.
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. 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/
Re: Staging repositories (was: Re: GSoC projects?)
Posted by Eshan Sudharaka <es...@gmail.com>.
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
On Tue, Apr 20, 2010 at 2:56 PM, Deng Ching <oc...@apache.org> wrote:
> +1 :)
>
> On Mon, Apr 19, 2010 at 9:29 AM, Brett Porter <br...@apache.org> wrote:
>
> > 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<http://people.apache.org/%7Ebrett/staging-promotion.png>
> <http://people.apache.org/%7Ebrett/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/
> >
> >
> >
> >
> >
>
--
P.A.Eshan Sudharaka
Dept of Computer Science and Engineering
University of Moratuwa
Sri Lanka
Re: Staging repositories (was: Re: GSoC projects?)
Posted by Deng Ching <oc...@apache.org>.
+1 :)
On Mon, Apr 19, 2010 at 9:29 AM, Brett Porter <br...@apache.org> wrote:
> 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<http://people.apache.org/%7Ebrett/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/
>
>
>
>
>
Re: Staging repositories (was: Re: GSoC projects?)
Posted by Brett Porter <br...@apache.org>.
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 <es...@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/
Re: Staging repositories (was: Re: GSoC projects?)
Posted by Brett Porter <br...@apache.org>.
On 12/04/2010, at 6:30 PM, Deng Ching wrote:
> On Mon, Apr 12, 2010 at 3:03 PM, Eshan Sudharaka <es...@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/
Re: Staging repositories (was: Re: GSoC projects?)
Posted by Deng Ching <oc...@apache.org>.
On Mon, Apr 12, 2010 at 3:03 PM, Eshan Sudharaka <es...@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.)?
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.
Thanks,
Deng
> On Mon, Apr 12, 2010 at 11:53 AM, Brett Porter <br...@apache.org> wrote:
>
> >
> > On 12/04/2010, at 3:25 PM, Eshan Sudharaka wrote:
> >
> > > hi Brett,
> > > i have already posted my proposal to the gsoc site.Could you please
> check
> > it
> > > and if there are any unclear parts or conflicts things please let me
> > > inform.I saw deng has already put comment on it.
> >
> > Yes, I've seen it - but not everyone on this list can :) I thought it
> might
> > be best to summarise here instead (or on the wiki when it is back up).
> >
> > My main comments would be the same as below - I'd like there to be at
> least
> > one staging repo per managed repo and minimal admin work.
> >
> > For permissions, I'm not sure we need new ones, just separate ones for
> > staging & managed resources (when the wiki is back up, I can point to the
> > document that says what roles, permissions and resources are). As an
> > example, say you have repo "releases" and attached repo
> "releases-staged".
> > There's no need to block read access to stage - you can give out the
> normal
> > repo read permission (and limit it to QAs or keep it as the same as the
> main
> > repo). Whoever has write perms to releases-staged can stage a release,
> > whoever has write permissions to releases can promote a release. I would
> say
> > write permissions to "releases" implies r/w permissions to
> > "releases-staged", but nothing else is implied.
> >
> > - Brett
> >
> > >
> > > On Mon, Apr 12, 2010 at 10:15 AM, Brett Porter <br...@apache.org>
> wrote:
> > >
> > >> Any further thoughts on this? Eshan, could you perhaps summarise your
> > >> proposal so far with the comments incorporated? Unfortunately, our
> wiki
> > is
> > >> still down which is the normal place to document the current state
> > between
> > >> discussions, but we can continue using the mailing list in the mean
> > time.
> > >>
> > >> On 06/04/2010, at 1:36 PM, Brett Porter wrote:
> > >>
> > >>>
> > >>> On 03/04/2010, at 8:25 AM, Dan Tran wrote:
> > >>>
> > >>>> From a build admin perspective, this what I would like to have:
> > >>>>
> > >>>>
> > >>>> 1. Create a permanent staging repository on archiva where I can
> > >>>> release/deploy all my projects one at the time.
> > >>>>
> > >>>> I can have multiple staging repos so that I can release multiple
> > >>>> project at the same time
> > >>>
> > >>> I agree to them being permanent - I'd prefer to be pointing Maven at
> > >> deploying to a staging repository, rather an automatically creating a
> > >> temporary one, and the staging repository should be available to Maven
> > users
> > >> without having to change it all the time. I think they must be
> attached
> > to a
> > >> particular managed repository, though, and this needs to be easy to do
> -
> > I
> > >> wouldn't want a lot of manual work each time and I definitely wouldn't
> > want
> > >> to be reconfiguring Maven for different deployments.
> > >>>
> > >>> This makes some sense for us since the permissions are currently
> > aligned
> > >> to the repositories, so we can grant a merging permission.
> > >>>
> > >>> The tools here should be reusable for similar use cases - for example
> > if
> > >> a proxy connector had a staging repository, we would be able to have
> an
> > >> approval process for third party artifacts that are requested.
> > >>>
> > >>>>
> > >>>> 2. Once the artifacts at a staging repos, I'd like it to merge the
> > >>>> staging repo into the official release repo. Finally wipe out the
> > >>>> staging repo's content
> > >>>
> > >>> It might be worth having the option of selecting which artifacts to
> > merge
> > >> (with default being all), then deleting those artifacts from the
> staging
> > >> repository.
> > >>>
> > >>> In the future, this could be made more intelligent by grouping
> > artifacts
> > >> automatically for merging (by using the modules, parents and
> > dependencies
> > >> elements to detect related artifacts that need to be moved together).
> > >>>
> > >>> Cheers,
> > >>> Brett
> > >>>
> > >>> --
> > >>> Brett Porter
> > >>> brett@apache.org
> > >>> http://brettporter.wordpress.com/
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >> --
> > >> Brett Porter
> > >> brett@apache.org
> > >> http://brettporter.wordpress.com/
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > > --
> > > P.A.Eshan Sudharaka
> > > Dept of Computer Science and Engineering
> > > University of Moratuwa
> > > Sri Lanka
> >
> > --
> > 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: Staging repositories (was: Re: GSoC projects?)
Posted by Eshan Sudharaka <es...@gmail.com>.
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
On Mon, Apr 12, 2010 at 11:53 AM, Brett Porter <br...@apache.org> wrote:
>
> On 12/04/2010, at 3:25 PM, Eshan Sudharaka wrote:
>
> > hi Brett,
> > i have already posted my proposal to the gsoc site.Could you please check
> it
> > and if there are any unclear parts or conflicts things please let me
> > inform.I saw deng has already put comment on it.
>
> Yes, I've seen it - but not everyone on this list can :) I thought it might
> be best to summarise here instead (or on the wiki when it is back up).
>
> My main comments would be the same as below - I'd like there to be at least
> one staging repo per managed repo and minimal admin work.
>
> For permissions, I'm not sure we need new ones, just separate ones for
> staging & managed resources (when the wiki is back up, I can point to the
> document that says what roles, permissions and resources are). As an
> example, say you have repo "releases" and attached repo "releases-staged".
> There's no need to block read access to stage - you can give out the normal
> repo read permission (and limit it to QAs or keep it as the same as the main
> repo). Whoever has write perms to releases-staged can stage a release,
> whoever has write permissions to releases can promote a release. I would say
> write permissions to "releases" implies r/w permissions to
> "releases-staged", but nothing else is implied.
>
> - Brett
>
> >
> > On Mon, Apr 12, 2010 at 10:15 AM, Brett Porter <br...@apache.org> wrote:
> >
> >> Any further thoughts on this? Eshan, could you perhaps summarise your
> >> proposal so far with the comments incorporated? Unfortunately, our wiki
> is
> >> still down which is the normal place to document the current state
> between
> >> discussions, but we can continue using the mailing list in the mean
> time.
> >>
> >> On 06/04/2010, at 1:36 PM, Brett Porter wrote:
> >>
> >>>
> >>> On 03/04/2010, at 8:25 AM, Dan Tran wrote:
> >>>
> >>>> From a build admin perspective, this what I would like to have:
> >>>>
> >>>>
> >>>> 1. Create a permanent staging repository on archiva where I can
> >>>> release/deploy all my projects one at the time.
> >>>>
> >>>> I can have multiple staging repos so that I can release multiple
> >>>> project at the same time
> >>>
> >>> I agree to them being permanent - I'd prefer to be pointing Maven at
> >> deploying to a staging repository, rather an automatically creating a
> >> temporary one, and the staging repository should be available to Maven
> users
> >> without having to change it all the time. I think they must be attached
> to a
> >> particular managed repository, though, and this needs to be easy to do -
> I
> >> wouldn't want a lot of manual work each time and I definitely wouldn't
> want
> >> to be reconfiguring Maven for different deployments.
> >>>
> >>> This makes some sense for us since the permissions are currently
> aligned
> >> to the repositories, so we can grant a merging permission.
> >>>
> >>> The tools here should be reusable for similar use cases - for example
> if
> >> a proxy connector had a staging repository, we would be able to have an
> >> approval process for third party artifacts that are requested.
> >>>
> >>>>
> >>>> 2. Once the artifacts at a staging repos, I'd like it to merge the
> >>>> staging repo into the official release repo. Finally wipe out the
> >>>> staging repo's content
> >>>
> >>> It might be worth having the option of selecting which artifacts to
> merge
> >> (with default being all), then deleting those artifacts from the staging
> >> repository.
> >>>
> >>> In the future, this could be made more intelligent by grouping
> artifacts
> >> automatically for merging (by using the modules, parents and
> dependencies
> >> elements to detect related artifacts that need to be moved together).
> >>>
> >>> Cheers,
> >>> Brett
> >>>
> >>> --
> >>> Brett Porter
> >>> brett@apache.org
> >>> http://brettporter.wordpress.com/
> >>>
> >>>
> >>>
> >>>
> >>
> >> --
> >> Brett Porter
> >> brett@apache.org
> >> http://brettporter.wordpress.com/
> >>
> >>
> >>
> >>
> >>
> >
> >
> > --
> > P.A.Eshan Sudharaka
> > Dept of Computer Science and Engineering
> > University of Moratuwa
> > Sri Lanka
>
> --
> 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: Staging repositories (was: Re: GSoC projects?)
Posted by Brett Porter <br...@apache.org>.
On 12/04/2010, at 3:25 PM, Eshan Sudharaka wrote:
> hi Brett,
> i have already posted my proposal to the gsoc site.Could you please check it
> and if there are any unclear parts or conflicts things please let me
> inform.I saw deng has already put comment on it.
Yes, I've seen it - but not everyone on this list can :) I thought it might be best to summarise here instead (or on the wiki when it is back up).
My main comments would be the same as below - I'd like there to be at least one staging repo per managed repo and minimal admin work.
For permissions, I'm not sure we need new ones, just separate ones for staging & managed resources (when the wiki is back up, I can point to the document that says what roles, permissions and resources are). As an example, say you have repo "releases" and attached repo "releases-staged". There's no need to block read access to stage - you can give out the normal repo read permission (and limit it to QAs or keep it as the same as the main repo). Whoever has write perms to releases-staged can stage a release, whoever has write permissions to releases can promote a release. I would say write permissions to "releases" implies r/w permissions to "releases-staged", but nothing else is implied.
- Brett
>
> On Mon, Apr 12, 2010 at 10:15 AM, Brett Porter <br...@apache.org> wrote:
>
>> Any further thoughts on this? Eshan, could you perhaps summarise your
>> proposal so far with the comments incorporated? Unfortunately, our wiki is
>> still down which is the normal place to document the current state between
>> discussions, but we can continue using the mailing list in the mean time.
>>
>> On 06/04/2010, at 1:36 PM, Brett Porter wrote:
>>
>>>
>>> On 03/04/2010, at 8:25 AM, Dan Tran wrote:
>>>
>>>> From a build admin perspective, this what I would like to have:
>>>>
>>>>
>>>> 1. Create a permanent staging repository on archiva where I can
>>>> release/deploy all my projects one at the time.
>>>>
>>>> I can have multiple staging repos so that I can release multiple
>>>> project at the same time
>>>
>>> I agree to them being permanent - I'd prefer to be pointing Maven at
>> deploying to a staging repository, rather an automatically creating a
>> temporary one, and the staging repository should be available to Maven users
>> without having to change it all the time. I think they must be attached to a
>> particular managed repository, though, and this needs to be easy to do - I
>> wouldn't want a lot of manual work each time and I definitely wouldn't want
>> to be reconfiguring Maven for different deployments.
>>>
>>> This makes some sense for us since the permissions are currently aligned
>> to the repositories, so we can grant a merging permission.
>>>
>>> The tools here should be reusable for similar use cases - for example if
>> a proxy connector had a staging repository, we would be able to have an
>> approval process for third party artifacts that are requested.
>>>
>>>>
>>>> 2. Once the artifacts at a staging repos, I'd like it to merge the
>>>> staging repo into the official release repo. Finally wipe out the
>>>> staging repo's content
>>>
>>> It might be worth having the option of selecting which artifacts to merge
>> (with default being all), then deleting those artifacts from the staging
>> repository.
>>>
>>> In the future, this could be made more intelligent by grouping artifacts
>> automatically for merging (by using the modules, parents and dependencies
>> elements to detect related artifacts that need to be moved together).
>>>
>>> Cheers,
>>> Brett
>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://brettporter.wordpress.com/
>>>
>>>
>>>
>>>
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://brettporter.wordpress.com/
>>
>>
>>
>>
>>
>
>
> --
> P.A.Eshan Sudharaka
> Dept of Computer Science and Engineering
> University of Moratuwa
> Sri Lanka
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
Re: Staging repositories (was: Re: GSoC projects?)
Posted by Eshan Sudharaka <es...@gmail.com>.
hi Dan,
this is the proposal which i submitted to the gsoc 2010 site.I think you may
have acces to the proposal as deng and brett.
Title: Add support for temporary repositories used for staging for
Archiva Student: Eshan Sudharaka Abstract: Creating a repository
where the users can deploy their artifacts and once
the testing tasks are completed user can deploy the artifact to the common
place where the we can use those artifacts as dependencies in pom files or
remove the artifact from the temporary repository if it fails during the
testing phase.
Proposal Title:Student Name:Student E-mail:
Proposal Title : Add support for temporary repositories used for staging for
Archiva
Student name : Patti Archchige Eshan Sudharaka
E-mail : esudharaka@gmail.com
IRC : irc://irc.codehaus.org/archiva
Organization/Project:Assigned Mentor:
Organization Name : Apache Software Foundation
Project : Apache Archiva
Assigned Mentor : Maria Odea Ching
Proposal Abstract:
Apache archiva is a repository management system where we can deploy our
artifacts to a common location and later on we can make use those artifacts
(jar files) in our projects by adding the artifacts as dependencies in the
POM file.But here there is no any separate place to deploy the artifacts
which are not tested yet and also the artifacts of an ongoing
project(modules).So we need to deploy them in to the common location where
the official artifacts are deployed.So there can be some issues due to use
of those artifacts as dependencies in our projects since they are not
properly tested.
So here my idea is to create a separate place (repositories) where the
registered user can deploy the staging artifacts.Those artifacts are not
visible to common users.Once the testing task is completed(ready for the
public deployment) we can either merge in to the common place where others
can make use of those artifacts or remove from the staging artifact(if it
fails).
Detailed Description*:*
First i would like to give a brief introduction about my approach to adding
the staging reposotory feature.
* *Adding a Staging Repository *
currenlty archiva comes with two default permanent repositories.Those are
internal repository and the snapshots repository.My idea is to add another
default repository called staging repository where the developpers can
deploy their ongoing(which have not being tested yet) .It is the admins task
to grant acces to the repository to users.Also no one(archiva artifacts
users) is allowed to use this repository as in the pom files as mensioned
in folllowing.
<pluginRepository>
<id>internal</id>
<url>http://192.168.0.7:8080/archiva/repository/staging<//url>
</pluginRepository>
So the visibility of the repository should be only with in the archiva
registererd users.
* *Creating Roles for this staging repository*
1) Read and Write acces to the repository
Here registered users can read and write articacts to the
repositaory. Here registered users mean develpers and thr QA
people.Developers have both read and write access where the QA people have
only the read access.
2) Promotion the Artifacts(merging to the common place)
This is the most important part in this project.Once the
testing tasks are done this role is responsible for merge artifacts from
staging repository to the internal repository or the snapshot repository.It
depends on the artifact(snapshot or a version).Here i am going to consider
following things regarding the merging the artifacts
* If the artifacts that are going to deploy is not an existing one(new
one) just deploy it with creating new meta data file.
* If the artifact is a new version of an existing artifact in the
internal repository and then deploy the artifact and also update the meta
data file.(exsisting one)
eg : lets say version 1.0 is available in internal repo and i need
to deploy version 1.1 to the internal repository form the staging
repository.
* There is another possibility in merging an artifact.Lets say in
internal repository we have version 1.1.x and we need to merge version
1.1.y(new one) to the internal repository from the staging repository.Here i
propose to have following functions.
1). Remove older one and deploye the latest version.(with
updating meta data files)
2). Deploy the latest version while keeping the older
version.(with updating the meta data files)
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.Also aditional
logs should be implemented for the staging reposotary.
*Time Line :*
May 24- June 6 : adding a default staging repository and assign the all
permissoin configurstions of that repository to the admin user
June 7 - June 12 : restricted this staging reposotory from being using as a
plugging repository from out user as mentioned in above in thire pom.xml
files
June 13 - June 28 : implementing the read action and the write actions and
assign them to the developer(role)and the QA person(role) as mentioned in
above.
June 29 -Jul 1 : Testing the roles(developer) with the staging repository.
July 2 - July 10 : implementing the promotion role.(only the merging based
on the assumption that new artifact is beign deployed.Not a update version)
July 11 - July 20 : implement the logs and make use them for the searching
algorithm to check the older versions of the artifacts which have already
deplyed.
July 12-Submit midterm evaluation
July 21- July 30 : add searching feature(action) to the promotion role and
do the merging part by providing the options regarding the versioning as
mensioned above.
July 31 - Auguest 5 : implementing logs for staging repository
Auguest 6 - Auguest 10 : testing phase
August 10-August 16 : Publish results and conclusion.
*About me : *
I am Eshan Sudharaka.(Patti Arachchige Eshan Sudharaka) and currently a
thrid year undergraduate of department of computer science and engineering
at university of moratuwa.Now i am under my intern period at hsenid mobile
solutions pvt.There we use archiva as internal repository and also we are
using lot of apache product such as maven , ant.It is a plesure to join with
the open source community and wish to have a long jorney.
On Mon, Apr 12, 2010 at 11:33 AM, Dan Tran <da...@gmail.com> wrote:
> Hi Eshan ,
>
> what is the link to that site?
>
> Thanks
>
> -Dan
>
> On Sun, Apr 11, 2010 at 10:25 PM, Eshan Sudharaka <es...@gmail.com>
> wrote:
> > hi Brett,
> > i have already posted my proposal to the gsoc site.Could you please check
> it
> > and if there are any unclear parts or conflicts things please let me
> > inform.I saw deng has already put comment on it.
> >
> > On Mon, Apr 12, 2010 at 10:15 AM, Brett Porter <br...@apache.org> wrote:
> >
> >> Any further thoughts on this? Eshan, could you perhaps summarise your
> >> proposal so far with the comments incorporated? Unfortunately, our wiki
> is
> >> still down which is the normal place to document the current state
> between
> >> discussions, but we can continue using the mailing list in the mean
> time.
> >>
> >> On 06/04/2010, at 1:36 PM, Brett Porter wrote:
> >>
> >> >
> >> > On 03/04/2010, at 8:25 AM, Dan Tran wrote:
> >> >
> >> >> From a build admin perspective, this what I would like to have:
> >> >>
> >> >>
> >> >> 1. Create a permanent staging repository on archiva where I can
> >> >> release/deploy all my projects one at the time.
> >> >>
> >> >> I can have multiple staging repos so that I can release multiple
> >> >> project at the same time
> >> >
> >> > I agree to them being permanent - I'd prefer to be pointing Maven at
> >> deploying to a staging repository, rather an automatically creating a
> >> temporary one, and the staging repository should be available to Maven
> users
> >> without having to change it all the time. I think they must be attached
> to a
> >> particular managed repository, though, and this needs to be easy to do -
> I
> >> wouldn't want a lot of manual work each time and I definitely wouldn't
> want
> >> to be reconfiguring Maven for different deployments.
> >> >
> >> > This makes some sense for us since the permissions are currently
> aligned
> >> to the repositories, so we can grant a merging permission.
> >> >
> >> > The tools here should be reusable for similar use cases - for example
> if
> >> a proxy connector had a staging repository, we would be able to have an
> >> approval process for third party artifacts that are requested.
> >> >
> >> >>
> >> >> 2. Once the artifacts at a staging repos, I'd like it to merge the
> >> >> staging repo into the official release repo. Finally wipe out the
> >> >> staging repo's content
> >> >
> >> > It might be worth having the option of selecting which artifacts to
> merge
> >> (with default being all), then deleting those artifacts from the staging
> >> repository.
> >> >
> >> > In the future, this could be made more intelligent by grouping
> artifacts
> >> automatically for merging (by using the modules, parents and
> dependencies
> >> elements to detect related artifacts that need to be moved together).
> >> >
> >> > Cheers,
> >> > Brett
> >> >
> >> > --
> >> > Brett Porter
> >> > brett@apache.org
> >> > http://brettporter.wordpress.com/
> >> >
> >> >
> >> >
> >> >
> >>
> >> --
> >> Brett Porter
> >> brett@apache.org
> >> http://brettporter.wordpress.com/
> >>
> >>
> >>
> >>
> >>
> >
> >
> > --
> > P.A.Eshan Sudharaka
> > Dept of Computer Science and Engineering
> > University of Moratuwa
> > Sri Lanka
> >
>
--
P.A.Eshan Sudharaka
Dept of Computer Science and Engineering
University of Moratuwa
Sri Lanka
Re: Staging repositories (was: Re: GSoC projects?)
Posted by Dan Tran <da...@gmail.com>.
Hi Eshan ,
what is the link to that site?
Thanks
-Dan
On Sun, Apr 11, 2010 at 10:25 PM, Eshan Sudharaka <es...@gmail.com> wrote:
> hi Brett,
> i have already posted my proposal to the gsoc site.Could you please check it
> and if there are any unclear parts or conflicts things please let me
> inform.I saw deng has already put comment on it.
>
> On Mon, Apr 12, 2010 at 10:15 AM, Brett Porter <br...@apache.org> wrote:
>
>> Any further thoughts on this? Eshan, could you perhaps summarise your
>> proposal so far with the comments incorporated? Unfortunately, our wiki is
>> still down which is the normal place to document the current state between
>> discussions, but we can continue using the mailing list in the mean time.
>>
>> On 06/04/2010, at 1:36 PM, Brett Porter wrote:
>>
>> >
>> > On 03/04/2010, at 8:25 AM, Dan Tran wrote:
>> >
>> >> From a build admin perspective, this what I would like to have:
>> >>
>> >>
>> >> 1. Create a permanent staging repository on archiva where I can
>> >> release/deploy all my projects one at the time.
>> >>
>> >> I can have multiple staging repos so that I can release multiple
>> >> project at the same time
>> >
>> > I agree to them being permanent - I'd prefer to be pointing Maven at
>> deploying to a staging repository, rather an automatically creating a
>> temporary one, and the staging repository should be available to Maven users
>> without having to change it all the time. I think they must be attached to a
>> particular managed repository, though, and this needs to be easy to do - I
>> wouldn't want a lot of manual work each time and I definitely wouldn't want
>> to be reconfiguring Maven for different deployments.
>> >
>> > This makes some sense for us since the permissions are currently aligned
>> to the repositories, so we can grant a merging permission.
>> >
>> > The tools here should be reusable for similar use cases - for example if
>> a proxy connector had a staging repository, we would be able to have an
>> approval process for third party artifacts that are requested.
>> >
>> >>
>> >> 2. Once the artifacts at a staging repos, I'd like it to merge the
>> >> staging repo into the official release repo. Finally wipe out the
>> >> staging repo's content
>> >
>> > It might be worth having the option of selecting which artifacts to merge
>> (with default being all), then deleting those artifacts from the staging
>> repository.
>> >
>> > In the future, this could be made more intelligent by grouping artifacts
>> automatically for merging (by using the modules, parents and dependencies
>> elements to detect related artifacts that need to be moved together).
>> >
>> > Cheers,
>> > Brett
>> >
>> > --
>> > Brett Porter
>> > brett@apache.org
>> > http://brettporter.wordpress.com/
>> >
>> >
>> >
>> >
>>
>> --
>> 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: Staging repositories (was: Re: GSoC projects?)
Posted by Eshan Sudharaka <es...@gmail.com>.
hi Brett,
i have already posted my proposal to the gsoc site.Could you please check it
and if there are any unclear parts or conflicts things please let me
inform.I saw deng has already put comment on it.
On Mon, Apr 12, 2010 at 10:15 AM, Brett Porter <br...@apache.org> wrote:
> Any further thoughts on this? Eshan, could you perhaps summarise your
> proposal so far with the comments incorporated? Unfortunately, our wiki is
> still down which is the normal place to document the current state between
> discussions, but we can continue using the mailing list in the mean time.
>
> On 06/04/2010, at 1:36 PM, Brett Porter wrote:
>
> >
> > On 03/04/2010, at 8:25 AM, Dan Tran wrote:
> >
> >> From a build admin perspective, this what I would like to have:
> >>
> >>
> >> 1. Create a permanent staging repository on archiva where I can
> >> release/deploy all my projects one at the time.
> >>
> >> I can have multiple staging repos so that I can release multiple
> >> project at the same time
> >
> > I agree to them being permanent - I'd prefer to be pointing Maven at
> deploying to a staging repository, rather an automatically creating a
> temporary one, and the staging repository should be available to Maven users
> without having to change it all the time. I think they must be attached to a
> particular managed repository, though, and this needs to be easy to do - I
> wouldn't want a lot of manual work each time and I definitely wouldn't want
> to be reconfiguring Maven for different deployments.
> >
> > This makes some sense for us since the permissions are currently aligned
> to the repositories, so we can grant a merging permission.
> >
> > The tools here should be reusable for similar use cases - for example if
> a proxy connector had a staging repository, we would be able to have an
> approval process for third party artifacts that are requested.
> >
> >>
> >> 2. Once the artifacts at a staging repos, I'd like it to merge the
> >> staging repo into the official release repo. Finally wipe out the
> >> staging repo's content
> >
> > It might be worth having the option of selecting which artifacts to merge
> (with default being all), then deleting those artifacts from the staging
> repository.
> >
> > In the future, this could be made more intelligent by grouping artifacts
> automatically for merging (by using the modules, parents and dependencies
> elements to detect related artifacts that need to be moved together).
> >
> > Cheers,
> > Brett
> >
> > --
> > Brett Porter
> > brett@apache.org
> > http://brettporter.wordpress.com/
> >
> >
> >
> >
>
> --
> 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: Staging repositories (was: Re: GSoC projects?)
Posted by Brett Porter <br...@apache.org>.
Any further thoughts on this? Eshan, could you perhaps summarise your proposal so far with the comments incorporated? Unfortunately, our wiki is still down which is the normal place to document the current state between discussions, but we can continue using the mailing list in the mean time.
On 06/04/2010, at 1:36 PM, Brett Porter wrote:
>
> On 03/04/2010, at 8:25 AM, Dan Tran wrote:
>
>> From a build admin perspective, this what I would like to have:
>>
>>
>> 1. Create a permanent staging repository on archiva where I can
>> release/deploy all my projects one at the time.
>>
>> I can have multiple staging repos so that I can release multiple
>> project at the same time
>
> I agree to them being permanent - I'd prefer to be pointing Maven at deploying to a staging repository, rather an automatically creating a temporary one, and the staging repository should be available to Maven users without having to change it all the time. I think they must be attached to a particular managed repository, though, and this needs to be easy to do - I wouldn't want a lot of manual work each time and I definitely wouldn't want to be reconfiguring Maven for different deployments.
>
> This makes some sense for us since the permissions are currently aligned to the repositories, so we can grant a merging permission.
>
> The tools here should be reusable for similar use cases - for example if a proxy connector had a staging repository, we would be able to have an approval process for third party artifacts that are requested.
>
>>
>> 2. Once the artifacts at a staging repos, I'd like it to merge the
>> staging repo into the official release repo. Finally wipe out the
>> staging repo's content
>
> It might be worth having the option of selecting which artifacts to merge (with default being all), then deleting those artifacts from the staging repository.
>
> In the future, this could be made more intelligent by grouping artifacts automatically for merging (by using the modules, parents and dependencies elements to detect related artifacts that need to be moved together).
>
> Cheers,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
>
>
>
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
Re: Staging repositories (was: Re: GSoC projects?)
Posted by Brett Porter <br...@apache.org>.
On 03/04/2010, at 8:25 AM, Dan Tran wrote:
> From a build admin perspective, this what I would like to have:
>
>
> 1. Create a permanent staging repository on archiva where I can
> release/deploy all my projects one at the time.
>
> I can have multiple staging repos so that I can release multiple
> project at the same time
I agree to them being permanent - I'd prefer to be pointing Maven at deploying to a staging repository, rather an automatically creating a temporary one, and the staging repository should be available to Maven users without having to change it all the time. I think they must be attached to a particular managed repository, though, and this needs to be easy to do - I wouldn't want a lot of manual work each time and I definitely wouldn't want to be reconfiguring Maven for different deployments.
This makes some sense for us since the permissions are currently aligned to the repositories, so we can grant a merging permission.
The tools here should be reusable for similar use cases - for example if a proxy connector had a staging repository, we would be able to have an approval process for third party artifacts that are requested.
>
> 2. Once the artifacts at a staging repos, I'd like it to merge the
> staging repo into the official release repo. Finally wipe out the
> staging repo's content
It might be worth having the option of selecting which artifacts to merge (with default being all), then deleting those artifacts from the staging repository.
In the future, this could be made more intelligent by grouping artifacts automatically for merging (by using the modules, parents and dependencies elements to detect related artifacts that need to be moved together).
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
Re: Staging repositories (was: Re: GSoC projects?)
Posted by Dan Tran <da...@gmail.com>.
>From a build admin perspective, this what I would like to have:
1. Create a permanent staging repository on archiva where I can
release/deploy all my projects one at the time.
I can have multiple staging repos so that I can release multiple
project at the same time
2. Once the artifacts at a staging repos, I'd like it to merge the
staging repo into the official release repo. Finally wipe out the
staging repo's content
I think Archiva should keep the requiment as simple as these.
Thanks
-Dan
On Fri, Apr 2, 2010 at 1:47 PM, Wendy Smoak <ws...@gmail.com> wrote:
> (I changed the subject line so it doesn't get lost in the generic discussion)
>
> On Fri, Apr 2, 2010 at 4:15 PM, eshan sudharaka <es...@gmail.com> wrote:
>
>> * Assign a Temporory reposotory for a group.(eg : com.MyTempRep.example)
>
> How do you think this should happen? Currently an admin has to create
> a repo and assign permissions before it can be used.
>
>> * Only they are allowed to publish artifacts and the tempo rory repo is only
>> open to them untill deploye the all artifacts to be tested.(not visible to
>> the common repo with have tesed modules)
>
> How would you determine that all the artifacts have been deployed?
>
>> * once the temporory reposotory is closed it should me prevented from the
>> developers being updating and it should be opened to QA people to
>> testing(Same temporory repo will be used.only acces grants should be chaged
>> and assing the acces for the QA group)
>
> Archiva doesn't currently know anything about 'developers' vs. 'QA'.
> It just has users with roles like repository manager or observer.
>
> Is this something you want to introduce?
>
>> * once testing is done > if it success then merge the temp repo to the
>> common repo(where the tested modules are located)
>> if it fails then manually removed from the repo.
>
> IMO, this is the most important part (the promotion/merge step) and it
> could be addressed separately from the roles/repo access part.
>
> In fact I'd like to be able to merge any two repositories, separately
> from any staging/promotion workflow. See
> http://jira.codehaus.org/browse/MRM-980
>
>> I dont understand how the audit log is linking with this project idea.could
>> u please explain it?
>
> The audit log needs to record all changes to the repositories.
> who/what/where, etc. That would apply to these staging repos as well.
>
> Unless it's already been changed, I remember the audit logging being a
> rather complex event driven thing. Don't get too bogged down in it if
> it looks scary, it probably needs to be reworked as a separate
> project.
>
>> and also are we need to wary about the changes that are done in the
>> artifacts in temporary repo (by developers).I mean whether we should provide
>> a facility like svn diff ?
>
> Once an artifact is deployed, it should not change. (I believe
> Archiva already prevents re-deploying a released [non-SNAPSHOT]
> artifact.) So no, I don't think a diff utility is needed.
>
> --
> Wendy
>