On Mon, Apr 5, 2010 at 4:01 PM, Eshan Sudharaka <[email protected]>wrote:
> On Mon, Apr 5, 2010 at 12:18 PM, Deng Ching <[email protected]> wrote: > > > On Mon, Apr 5, 2010 at 8:55 AM, eshan sudharaka <[email protected] > > >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 <[email protected]> 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 <[email protected]> > 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 < > > [email protected] > > > > > > > >> 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 >
