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.
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).
First i would like to give a brief introduction about my approach to adding the staging repository feature.
currently archiva has two permanent repositories called internal and the snapshot. Here my idea is to propose intermediate staging repository to deploy artifacts which have been not tested yet. It is the archiva user's task to create this permanent staging repository and attached it for a selected repository. Following example will illustrate that scenario.
Lets say user has a repository called “data_repo” and he needs to get the support of staging repository. Then he has to create staging repository instance called “data_repo_stage” and he can attached this stage repository to his main repository called “data_repo”.(hope to offer this function through the web interface).Here user can add more than one stage repositories so that simultaneous releasing function will support. Promotion is done through the following path.
data_repo_stage >>> data_repo
I think in the stage repository we should limit the access. Nobody should allow to download the artifacts in the staging repositories other than the developers,QA people, archiva admin user ,and the the guy who have the permission for the promotion.
I think it is the repository manager's task to create the stage repositories and attach it to the main repository that he want to add the staging functionality.
Here registered users can read and write artifacts to the repository. Here registered users mean developers and the QA people.Here developers should have both read and write access while the QA guys have only the read access. Also QA guys should be able to mark the artifact as success one or a failure on. Then it will be useful for the merging part to take a correct decision.
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. (user should me able to merge the artifact by clicking the merge button and then should receive to success/failure message from the archiva side)
If the artifact is an existing one(in the case of re-release) we need to provide following options.
when the user clicks merge button (in the case of re-release) it should notify the user about the existing version in the release repository.(eg : version number + updated date)
then we need to suggest him following options.
In above I have mentioned only the success scenario of a artifact. There can be a fail scenario as well. If an artifact is failed then the user should manually delete the artifact