archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eshan Sudharaka <>
Subject Re: Staging repositories (was: Re: GSoC projects?)
Date Mon, 12 Apr 2010 06:45:20 GMT
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

Student name : Patti Archchige Eshan Sudharaka

E-mail  :

IRC     : irc://

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

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.


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

    * 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

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

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

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 <> wrote:

> Hi Eshan ,
> what is the link to that site?
> Thanks
> -Dan
> On Sun, Apr 11, 2010 at 10: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.
> >
> > On Mon, Apr 12, 2010 at 10:15 AM, Brett Porter <> 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 Porter
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> > --
> > 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message