archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deng Ching <>
Subject Re: procedure for the stage repo merge implementation
Date Mon, 24 May 2010 02:21:15 GMT
Hi Eshan,

Thanks for sending this out in the dev list. I think you're on the right
track especially wrt to using the new repository API. I just have a couple
more things I'd like to change in the flow, please see comments below :)

On Sun, May 23, 2010 at 12:29 PM, Eshan Sudharaka <>wrote:

> here i have mentioned the the flow of the staging functionality.based on
> this i am going to create the class diagram.(i need to be speed up since
> gsoc coding time period will be staring tomorrow onwards ). i am waiting for
> comments of you guys.
> gather details of repository(source repo) that we are going to merge
>   * Source artifact details
>          1). group id
>          2). artifact id
>          3). version
>          (above tree can be find out using RepositoryMetaDataReader class)
>          4). sorce address(where the repo is located)
>          5). addresses of the artifact pom file and the jar file to be
> merged
> gather details of target repository which the artifacts to be merged
>          1). search for the folder which is named by the group id(source
> artifact group id)
>          2). search for the folder which is names by the artifact id(sorce
> artifact id)
>          3). search for the filder which is named by the artifact
> version(source artifact version)

I think you can already search or check for the artifact directly (using the
artifact coordinates) without the need to check separately for the groupId,
artifactId and artifact version. For example, the artifact to be merged is
"org.apache.archiva:archiva-test:1.0", you can already search/check the
target repository directly by passing the groupId, artifactId and version as
parameters to one of the get methods of the metadata resolver class..

>          (above searching may be vary according to the avalability of the
> artifacts in the target repo)
>          we can use MetaDataResolver class for this task.
> here we need to consider following use cases
Given what I said above, the conditions below will have to change..

> * folder named by gruop id is not found in the target repo
>      here we have to create following directory structure in side the repo
>              group id folder > artifact id folder(which is same as artifact
> id of source repo)
>      then we need to folder named with the artifact version in side the
> artifact id folder
>      then copy the source pom file and jar file in to that folder.
>      then we need to create maven meta data xml file, sha1 and md5 files.
>      finally we need to create archiva meta data model for that
> artifact.(in side the .archiva folder)
> * folder named by group id is found. but there is no folder called artifact
> id inside the gruop id folder
>      here we need to create a folder named by artifact id follow the same
> steps as  above.

The above two conditions can already be merged or changed to "if the
artifact does not exist, then do the following":
- create the artifact directory structure
- copy the artifact together with the POM file and other related artifacts
such as javadoc jars, source jars, etc. from the source repo to the target
- create the artifact level (the one under the version/ dir)
maven-metadata.xml, sha1 & mda5 checksum files
- merge the project level (the one under the artifact/ dir)
maven-metadata.xml from the source repository with the one in the target
- create archiva metadata model for the artifact (inside the .archiva

> * when the version is already exist
>      this is hopefully to done in 2nd iteration.introduce the artifact
> replacing functionality.
>  thank you .


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