Page History

...

currently 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 developers can deploy their ongoing(which have not being tested yet) .It is the admins task to grant access to the repository to users.Also no one(archiva artifacts users) is allowed to use this repository as in the pom files as mentioned in following.<pluginRepository>

<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

...

Read and Write access to the repository

Here registered users can read and write artifacts to the repository. Here registered users mean developers and the 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 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 deploy the latest version.(with updating meta data files)

...

• 1. 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 follow and provide above functionalities to the user.Also additional logs should be implemented for the staging repository.Steps:

Implementation

1. adding a default staging repository and assign the all permissoin configurations of that repository to the admin user
2. restricted this staging repository from being using as a plugging repository from out user as mentioned in above in the pom.xml files
3. implementing the read action and the write actions and assign them to the developer(role)and the QA person(role) as mentioned in above.
4. Testing the roles(developer) with the staging repository.
5. implementing the promotion role.(only the merging based on the assumption that new artifact is being deployed.Not a update version)
6. implement the logs and make use them for the searching algorithm to check the older versions of the artifacts which have already deployed.
7. add searching feature(action) to the promotion role and do the merging part by providing the options regarding the version as mentioned above.
8. implementing logs for staging repository