You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@archiva.apache.org by Eshan Sudharaka <es...@gmail.com> on 2010/05/23 06:29:23 UTC
procedure for the stage repo merge implementation
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)
(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
* 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.
* when the version is already exist
this is hopefully to done in 2nd iteration.introduce the artifact
replacing functionality.
thank you .
--
P.A.Eshan Sudharaka
Dept of Computer Science and Engineering
University of Moratuwa
Sri Lanka
Re: procedure for the stage repo merge implementation
Posted by Deng Ching <oc...@apache.org>.
On Wed, May 26, 2010 at 12:28 PM, Eshan Sudharaka <es...@gmail.com>wrote:
> so can we use following classes to merage repo
> 1) MavenMetadata creation , Sha1, Md5 creation >>> using available archiva
> classes
> 2) gather all artifacts details in source repo >>> using available
> archiva
> classes
> 3) gather all artifact detais of target repo >>>> using available archiva
> classes
> 4) directory structure creation with getting details from 2) and 3)
> 5) handling jar, pom merging.(copying and replacing actions are done
> here)
>
> once those things are done we can think about archiva meta data model
> updating functionality.
>
Yes, sounds good.
Thanks,
Deng
Re: procedure for the stage repo merge implementation
Posted by Eshan Sudharaka <es...@gmail.com>.
so can we use following classes to merage repo
1) MavenMetadata creation , Sha1, Md5 creation >>> using available archiva
classes
2) gather all artifacts details in source repo >>> using available archiva
classes
3) gather all artifact detais of target repo >>>> using available archiva
classes
4) directory structure creation with getting details from 2) and 3)
5) handling jar, pom merging.(copying and replacing actions are done here)
once those things are done we can think about archiva meta data model
updating functionality.
On Tue, May 25, 2010 at 12:16 PM, Eshan Sudharaka <es...@gmail.com>wrote:
>
>
> On Tue, May 25, 2010 at 11:59 AM, Deng Ching <oc...@apache.org> wrote:
>
>> On Tue, May 25, 2010 at 12:12 PM, Eshan Sudharaka <esudharaka@gmail.com
>> >wrote:
>>
>> > > >
>> > > >
>> > > Just to be clear again, you don't need to write/create the
>> > > MavenMetaDataCreator, Sh1Creator and MD5Creator classes since we
>> already
>> > > have them in Archiva. Take a look at the UploadAction in
>> archiva-webapp
>> > and
>> > > see how the metadata and checksums are generated. It might be
>> worthwhile
>> > to
>> > > move out the code for this from the action class so you can re-use it
>> in
>> > > the
>> > > merging.
>> > >
>> >
>> > >>>> so can we use one class to to get ther services from available
>> > classes in archiva..?
>> >
>>
>> Yes :)
>>
>>
>> >
>> > >
>> > > I'm confused about the TargetArtifactDetails, what is the difference
>> > > between
>> > > the sourceArtifactDetailsList, availableArtifactList and
>> > > notAvailableArtifactList?
>> >
>> > >>>> if the artifact version that we are going to merge is already in
>> > the target repository i am going to put it in to availableArtifactList
>> > since we need to perforn two diffferent actions for both(target repo hit
>> > and
>> > target repo not hit)
>> >
>> >
>> So is it correct to assume that the TargetArtifactDetails class will
>> contain
>> info about the target repository and not a specific target artifact?
>>
>
>
>> >>>>> ya. it is contains info about target repository.We can produce
>> available artifacts list in the sorce repo and check those are availble in
>> target repo using TargetRepoDetails class(as u have mentioned better to
>> rename the TargetArtifactDetails in to TargetRepoDetails). once we have
>> compared then we can create the directiry structure.
>>
>>
>> >
>> > > The name of the class itself is also a bit
>> > > confusing.. It seems that it contains information about the target
>> > > repository, so maybe it should be renamed TargetRepositoryDetails?
>> >
>>
>>
>> Thanks,
>> Deng
>>
>
>
>
> --
> 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
Re: procedure for the stage repo merge implementation
Posted by Eshan Sudharaka <es...@gmail.com>.
On Tue, May 25, 2010 at 11:59 AM, Deng Ching <oc...@apache.org> wrote:
> On Tue, May 25, 2010 at 12:12 PM, Eshan Sudharaka <esudharaka@gmail.com
> >wrote:
>
> > > >
> > > >
> > > Just to be clear again, you don't need to write/create the
> > > MavenMetaDataCreator, Sh1Creator and MD5Creator classes since we
> already
> > > have them in Archiva. Take a look at the UploadAction in archiva-webapp
> > and
> > > see how the metadata and checksums are generated. It might be
> worthwhile
> > to
> > > move out the code for this from the action class so you can re-use it
> in
> > > the
> > > merging.
> > >
> >
> > >>>> so can we use one class to to get ther services from available
> > classes in archiva..?
> >
>
> Yes :)
>
>
> >
> > >
> > > I'm confused about the TargetArtifactDetails, what is the difference
> > > between
> > > the sourceArtifactDetailsList, availableArtifactList and
> > > notAvailableArtifactList?
> >
> > >>>> if the artifact version that we are going to merge is already in
> > the target repository i am going to put it in to availableArtifactList
> > since we need to perforn two diffferent actions for both(target repo hit
> > and
> > target repo not hit)
> >
> >
> So is it correct to assume that the TargetArtifactDetails class will
> contain
> info about the target repository and not a specific target artifact?
>
> >>>>> ya. it is contains info about target repository.We can produce
> available artifacts list in the sorce repo and check those are availble in
> target repo using TargetRepoDetails class(as u have mentioned better to
> rename the TargetArtifactDetails in to TargetRepoDetails). once we have
> compared then we can create the directiry structure.
>
> >
> > > The name of the class itself is also a bit
> > > confusing.. It seems that it contains information about the target
> > > repository, so maybe it should be renamed TargetRepositoryDetails?
> >
>
>
> Thanks,
> Deng
>
--
P.A.Eshan Sudharaka
Dept of Computer Science and Engineering
University of Moratuwa
Sri Lanka
Re: procedure for the stage repo merge implementation
Posted by Deng Ching <oc...@apache.org>.
On Tue, May 25, 2010 at 12:12 PM, Eshan Sudharaka <es...@gmail.com>wrote:
> > >
> > >
> > Just to be clear again, you don't need to write/create the
> > MavenMetaDataCreator, Sh1Creator and MD5Creator classes since we already
> > have them in Archiva. Take a look at the UploadAction in archiva-webapp
> and
> > see how the metadata and checksums are generated. It might be worthwhile
> to
> > move out the code for this from the action class so you can re-use it in
> > the
> > merging.
> >
>
> >>>> so can we use one class to to get ther services from available
> classes in archiva..?
>
Yes :)
>
> >
> > I'm confused about the TargetArtifactDetails, what is the difference
> > between
> > the sourceArtifactDetailsList, availableArtifactList and
> > notAvailableArtifactList?
>
> >>>> if the artifact version that we are going to merge is already in
> the target repository i am going to put it in to availableArtifactList
> since we need to perforn two diffferent actions for both(target repo hit
> and
> target repo not hit)
>
>
So is it correct to assume that the TargetArtifactDetails class will contain
info about the target repository and not a specific target artifact?
>
> > The name of the class itself is also a bit
> > confusing.. It seems that it contains information about the target
> > repository, so maybe it should be renamed TargetRepositoryDetails?
>
Thanks,
Deng
Re: procedure for the stage repo merge implementation
Posted by Eshan Sudharaka <es...@gmail.com>.
On Tue, May 25, 2010 at 9:19 AM, Deng Ching <od...@gmail.com> wrote:
> On Tue, May 25, 2010 at 7:52 AM, Eshan Sudharaka <esudharaka@gmail.com
> >wrote:
>
> > here i have attached class diagrams for stage repo merge.(only for gather
> > source artifact details + target repo details + copy jar + pom +merge
> maven
> > metadata )
> >
> >
> > On Mon, May 24, 2010 at 4:47 PM, Eshan Sudharaka <esudharaka@gmail.com
> >wrote:
> >
> >>
> >> 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 artifact version in the target repo( using
> >> metadataresolver class)
> >>
> >> >>>>>> ArtifactMergeDetails class (with appropriate variables
> and
> >> metods)
> >>
> >>
> >> here we need to consider following use cases
> >>
> >> * version that we are going to merge is not found on target repo
> >> 1) 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)
> >> 2) then we need to folder named with the artifact version in side
> the
> >> artifact id folder
> >>
> >> 3) then copy the source pom file and jar file in to that folder.
> >>
> >> >>>> ArtifactMerge class (will do above 1,2,3 task)
> >>
> >>
> >> then we need to create maven meta data xml file, sha1 and md5
> files.
> >> >>>>> MavenMetaDataCreator class , Sha1Creator class MD5cREATOR
> >> class will do above tasks
> >
> >
> Just to be clear again, you don't need to write/create the
> MavenMetaDataCreator, Sh1Creator and MD5Creator classes since we already
> have them in Archiva. Take a look at the UploadAction in archiva-webapp and
> see how the metadata and checksums are generated. It might be worthwhile to
> move out the code for this from the action class so you can re-use it in
> the
> merging.
>
>>>> so can we use one class to to get ther services from available
classes in archiva..?
>
> I'm confused about the TargetArtifactDetails, what is the difference
> between
> the sourceArtifactDetailsList, availableArtifactList and
> notAvailableArtifactList?
>>>> if the artifact version that we are going to merge is already in
the target repository i am going to put it in to availableArtifactList
since we need to perforn two diffferent actions for both(target repo hit and
target repo not hit)
> The name of the class itself is also a bit
> confusing.. It seems that it contains information about the target
> repository, so maybe it should be renamed TargetRepositoryDetails?
>
> As for the SourceArtifactDetails, I'm not sure if this is still needed with
> the repository API (since the path to the artifact can already be resolved
> on the fly).
>
>
> Thanks,
> Deng
>
--
P.A.Eshan Sudharaka
Dept of Computer Science and Engineering
University of Moratuwa
Sri Lanka
Re: procedure for the stage repo merge implementation
Posted by Deng Ching <od...@gmail.com>.
On Tue, May 25, 2010 at 7:52 AM, Eshan Sudharaka <es...@gmail.com>wrote:
> here i have attached class diagrams for stage repo merge.(only for gather
> source artifact details + target repo details + copy jar + pom +merge maven
> metadata )
>
>
> On Mon, May 24, 2010 at 4:47 PM, Eshan Sudharaka <es...@gmail.com>wrote:
>
>>
>> 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 artifact version in the target repo( using
>> metadataresolver class)
>>
>> >>>>>> ArtifactMergeDetails class (with appropriate variables and
>> metods)
>>
>>
>> here we need to consider following use cases
>>
>> * version that we are going to merge is not found on target repo
>> 1) 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)
>> 2) then we need to folder named with the artifact version in side the
>> artifact id folder
>>
>> 3) then copy the source pom file and jar file in to that folder.
>>
>> >>>> ArtifactMerge class (will do above 1,2,3 task)
>>
>>
>> then we need to create maven meta data xml file, sha1 and md5 files.
>> >>>>> MavenMetaDataCreator class , Sha1Creator class MD5cREATOR
>> class will do above tasks
>
>
Just to be clear again, you don't need to write/create the
MavenMetaDataCreator, Sh1Creator and MD5Creator classes since we already
have them in Archiva. Take a look at the UploadAction in archiva-webapp and
see how the metadata and checksums are generated. It might be worthwhile to
move out the code for this from the action class so you can re-use it in the
merging.
I'm confused about the TargetArtifactDetails, what is the difference between
the sourceArtifactDetailsList, availableArtifactList and
notAvailableArtifactList? The name of the class itself is also a bit
confusing.. It seems that it contains information about the target
repository, so maybe it should be renamed TargetRepositoryDetails?
As for the SourceArtifactDetails, I'm not sure if this is still needed with
the repository API (since the path to the artifact can already be resolved
on the fly).
Thanks,
Deng
Re: procedure for the stage repo merge implementation
Posted by Eshan Sudharaka <es...@gmail.com>.
here i have attached class diagrams for stage repo merge.(only for gather
source artifact details + target repo details + copy jar + pom +merge maven
metadata )
On Mon, May 24, 2010 at 4:47 PM, Eshan Sudharaka <es...@gmail.com>wrote:
>
> 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 artifact version in the target repo( using
> metadataresolver class)
>
> >>>>>> ArtifactMergeDetails class (with appropriate variables and
> metods)
>
>
> here we need to consider following use cases
>
> * version that we are going to merge is not found on target repo
> 1) 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)
> 2) then we need to folder named with the artifact version in side the
> artifact id folder
>
> 3) then copy the source pom file and jar file in to that folder.
>
> >>>> ArtifactMerge class (will do above 1,2,3 task)
>
>
> then we need to create maven meta data xml file, sha1 and md5 files.
> >>>>> MavenMetaDataCreator class , Sha1Creator class MD5cREATOR class
> will do above tasks
>
>
> finally we need to create archiva meta data model for that
> artifact.(in side the .archiva folder)
>
> >>>>> Hope to use seperate package to do this.
>
>
>
> * when the version is already exist
> this is hopefully to done in 2nd iteration.introduce the artifact
> replacing functionality.
>
> is it possible to work on above three classes ?. I feel those are
> independent with others.
>
> On Mon, May 24, 2010 at 7:51 AM, Deng Ching <oc...@apache.org> wrote:
>
>> 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 <esudharaka@gmail.com
>> >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
>> repository
>> - 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
>> repository
>> - create archiva metadata model for the artifact (inside the .archiva
>> folder)
>>
>>
>> >
>> > * when the version is already exist
>> > this is hopefully to done in 2nd iteration.introduce the artifact
>> > replacing functionality.
>> >
>> > thank you .
>> >
>> >
>>
>> Thanks,
>> Deng
>>
>
>
>
> --
> 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
Re: procedure for the stage repo merge implementation
Posted by Eshan Sudharaka <es...@gmail.com>.
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 artifact version in the target repo( using
metadataresolver class)
>>>>>> ArtifactMergeDetails class (with appropriate variables and
metods)
here we need to consider following use cases
* version that we are going to merge is not found on target repo
1) 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)
2) then we need to folder named with the artifact version in side the
artifact id folder
3) then copy the source pom file and jar file in to that folder.
>>>> ArtifactMerge class (will do above 1,2,3 task)
then we need to create maven meta data xml file, sha1 and md5 files.
>>>>> MavenMetaDataCreator class , Sha1Creator class MD5cREATOR class
will do above tasks
finally we need to create archiva meta data model for that artifact.(in
side the .archiva folder)
>>>>> Hope to use seperate package to do this.
* when the version is already exist
this is hopefully to done in 2nd iteration.introduce the artifact
replacing functionality.
is it possible to work on above three classes ?. I feel those are
independent with others.
On Mon, May 24, 2010 at 7:51 AM, Deng Ching <oc...@apache.org> wrote:
> 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 <esudharaka@gmail.com
> >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
> repository
> - 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
> repository
> - create archiva metadata model for the artifact (inside the .archiva
> folder)
>
>
> >
> > * when the version is already exist
> > this is hopefully to done in 2nd iteration.introduce the artifact
> > replacing functionality.
> >
> > thank you .
> >
> >
>
> Thanks,
> Deng
>
--
P.A.Eshan Sudharaka
Dept of Computer Science and Engineering
University of Moratuwa
Sri Lanka
Re: procedure for the stage repo merge implementation
Posted by Deng Ching <oc...@apache.org>.
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 <es...@gmail.com>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
repository
- 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
repository
- create archiva metadata model for the artifact (inside the .archiva
folder)
>
> * when the version is already exist
> this is hopefully to done in 2nd iteration.introduce the artifact
> replacing functionality.
>
> thank you .
>
>
Thanks,
Deng