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/29 04:37:24 UTC
design for sourceArtifactDetails class
here i have attached the basic structure of the class. And i want to know
do i need to implement a search method to iterate through the folder
structure and find the maven meta data XML files ? or that functionality is
al;ready there in archiva code base ?
--
P.A.Eshan Sudharaka
Dept of Computer Science and Engineering
University of Moratuwa
Sri Lanka
Re: design for sourceArtifactDetails class
Posted by Deng Ching <oc...@apache.org>.
On Fri, Jun 11, 2010 at 3:24 AM, Eshan Sudharaka <es...@gmail.com>wrote:
> I tried to get some services from the DefaultMetaDataResolver class. Since
> i
> dont have following objects it is throwing nul pointer exceptions.
> * private MetadataRepository metadataRepository;
> * private StorageMetadataResolver storageResolver;
>
> stack trace :
> java.lang.NullPointerException
> at
>
> org.apache.archiva.metadata.repository.DefaultMetadataResolver.getRootNamespaces(DefaultMetadataResolver.java:122)
>
> As deng mentioned those objects are injected by plexes by the
> @plexus.requirement annotation. But here that annotation is commented. But
> in components.xml i saw those objects as reqiurements.
>
> Here actually I want to know how do we inject those objects when we are
> using that DefaultMetadataResolver class in another module.?
>
Did you add the @plexus.requirement annotation for the MetadataResolver
variable declaration in your class? The components of the MetadataResolver
class should have already been injected.
Thanks,
Deng
Re: design for sourceArtifactDetails class
Posted by Eshan Sudharaka <es...@gmail.com>.
I tried to get some services from the DefaultMetaDataResolver class. Since i
dont have following objects it is throwing nul pointer exceptions.
* private MetadataRepository metadataRepository;
* private StorageMetadataResolver storageResolver;
stack trace :
java.lang.NullPointerException
at
org.apache.archiva.metadata.repository.DefaultMetadataResolver.getRootNamespaces(DefaultMetadataResolver.java:122)
As deng mentioned those objects are injected by plexes by the
@plexus.requirement annotation. But here that annotation is commented. But
in components.xml i saw those objects as reqiurements.
Here actually I want to know how do we inject those objects when we are
using that DefaultMetadataResolver class in another module.?
thankz.
On Thu, Jun 10, 2010 at 12:05 PM, Deng Ching <oc...@apache.org> wrote:
> On Fri, Jun 4, 2010 at 8:49 AM, Eshan Sudharaka <esudharaka@gmail.com
> >wrote:
>
> > get info about the source repo :
> >
> > * can we have a implementation of following method in Metadata
> Resolver
> > class.
> >
>
> > public Collection<ArtifactMetadata> getArtifacts( String
> repoId,
> > String namespace, String projectId,
> > String
> projectVersion
> > )
>
>
> Isn't this already part of the MetadataResolver?
>
>
> > here we need to set the repoId and the list of
> >
> > 1).available namespaces
> >
> > * i had a look in to FileMetadataRepository class
> >
> > public Collection<String> getNamespaces( String
> > repoId, String baseNamespace )
> > so what is this baseNamespace ..?
> >
>
> This is the same as the rootNamespace..
>
>
> > i think if we can pass this basename we can get the
> > list of available namespaces
> >
> > 2). available list of projectId
> >
> > * public Collection<String> getProjects( String
> repoId,
> > String namespace )
> > we can use impl of this method.
> >
> >
> > 3). available project versions list
> >
> > * public Collection<String> getProjectVersions(
> > String repoId, String namespace, String projectId )
> > 4). repo id -this is our input to the system
> >
> > after getting details we can map repoId, namespace,
> > projectId, projectVersion for a particular project.
> >
> >
> > I had a problem regarding getArtifacts method mensioned in
> above.
> > We are passing parameters for a particula artifact. so how it returns a
> > list
> > of
> > ArtifactMetadata ..?
> >
> >
> Remember, the MetadataResolver is for the metadata repository that's why it
> returns a list of ArtifactMetadata :)
>
> Thanks,
> Deng
>
--
P.A.Eshan Sudharaka
Dept of Computer Science and Engineering
University of Moratuwa
Sri Lanka
Re: design for sourceArtifactDetails class
Posted by Deng Ching <oc...@apache.org>.
On Fri, Jun 4, 2010 at 8:49 AM, Eshan Sudharaka <es...@gmail.com>wrote:
> get info about the source repo :
>
> * can we have a implementation of following method in Metadata Resolver
> class.
>
> public Collection<ArtifactMetadata> getArtifacts( String repoId,
> String namespace, String projectId,
> String projectVersion
> )
Isn't this already part of the MetadataResolver?
> here we need to set the repoId and the list of
>
> 1).available namespaces
>
> * i had a look in to FileMetadataRepository class
>
> public Collection<String> getNamespaces( String
> repoId, String baseNamespace )
> so what is this baseNamespace ..?
>
This is the same as the rootNamespace..
> i think if we can pass this basename we can get the
> list of available namespaces
>
> 2). available list of projectId
>
> * public Collection<String> getProjects( String repoId,
> String namespace )
> we can use impl of this method.
>
>
> 3). available project versions list
>
> * public Collection<String> getProjectVersions(
> String repoId, String namespace, String projectId )
> 4). repo id -this is our input to the system
>
> after getting details we can map repoId, namespace,
> projectId, projectVersion for a particular project.
>
>
> I had a problem regarding getArtifacts method mensioned in above.
> We are passing parameters for a particula artifact. so how it returns a
> list
> of
> ArtifactMetadata ..?
>
>
Remember, the MetadataResolver is for the metadata repository that's why it
returns a list of ArtifactMetadata :)
Thanks,
Deng
Re: design for sourceArtifactDetails class
Posted by Eshan Sudharaka <es...@gmail.com>.
get info about the source repo :
* can we have a implementation of following method in Metadata Resolver
class.
public Collection<ArtifactMetadata> getArtifacts( String repoId,
String namespace, String projectId,
String projectVersion
)
here we need to set the repoId and the list of
1).available namespaces
* i had a look in to FileMetadataRepository class
public Collection<String> getNamespaces( String
repoId, String baseNamespace )
so what is this baseNamespace ..?
i think if we can pass this basename we can get the
list of available namespaces
2). available list of projectId
* public Collection<String> getProjects( String repoId,
String namespace )
we can use impl of this method.
3). available project versions list
* public Collection<String> getProjectVersions(
String repoId, String namespace, String projectId )
4). repo id -this is our input to the system
after getting details we can map repoId, namespace,
projectId, projectVersion for a particular project.
I had a problem regarding getArtifacts method mensioned in above.
We are passing parameters for a particula artifact. so how it returns a list
of
ArtifactMetadata ..?
On Thu, Jun 3, 2010 at 9:54 AM, Eshan Sudharaka <es...@gmail.com>wrote:
> is there a way to get the meta data repo for a particula repo. as i
> understood we can get all details of the repository by using itz meta data
> repository. (i follwed the DefaultMetadataResolver class.)
>
>
> On Wed, Jun 2, 2010 at 2:24 PM, Deng Ching <oc...@apache.org> wrote:
>
>> Did you check the MetadataResolver class? I think you can get the
>> artifacts
>> in the repository from there.. :)
>>
>> -Deng
>>
>> On Wed, Jun 2, 2010 at 4:48 PM, Eshan Sudharaka <esudharaka@gmail.com
>> >wrote:
>>
>> > On Wed, Jun 2, 2010 at 12:17 PM, Deng Ching <oc...@apache.org> wrote:
>> >
>> > > In that case, I don't think you'd need the readMetadata(..) method?
>> >
>> > here i am confusing. how do we know what are the avialable artifacts is
>> > the
>> > repository with out reading the maven meta data xml file..? my approach
>> was
>> > to get the list of available artifacts in the source repo by reading
>> the
>> > maven meta data xml file. then i am going to pass the maven meta data
>> xml
>> > file to read (by using archiva existing class).So i need to find a way
>> to
>> > search the maven meta data file(location). So it can be implemented in
>> > another class.
>> >
>> >
>> > > As for
>> > > the searchRepo(..) method, I think this should be moved out of the
>> class
>> > > into a separate one since it is not specific for the source
>> repository,
>> > but
>> > > rather to the target repository.
>> > >
>> > >
>> >
>> > > It would also be good to change the name of the class to make it more
>> > > descriptive of what it intends to do..
>> > >
>> > > Thanks,
>> > > Deng
>> > >
>> > > On Tue, Jun 1, 2010 at 2:03 PM, Eshan Sudharaka <esudharaka@gmail.com
>> > > >wrote:
>> > >
>> > > > On Tue, Jun 1, 2010 at 11:20 AM, Deng Ching <oc...@apache.org>
>> wrote:
>> > > >
>> > > > > Thanks for attaching the diagram in the wiki page :)
>> > > > >
>> > > > > Right now, I'm not sure what the SourceArtifactDetails is
>> > specifically
>> > > > for.
>> > > > > From the last diagram you sent in the previous thread (
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>> http://old.nabble.com/procedure-for-the-stage-repo-merge-implementation-td28647541.html
>> > > > > ),
>> > > > > I thought it was for a source artifact. But now, it looks like
>> it's
>> > > > > specifically for the source repository?
>> > > > >
>> > > > > ya. It gather information of source repository that we are
>> going
>> > to
>> > > > mearge. once we have a source artifact list then we can search
>> through
>> > > the
>> > > > destination repository and copy them.
>> > > >
>> > > > since i am going to introduce both replacing(for available artifact
>> in
>> > > > target repo) and copying i thought it is better to gather
>> information
>> > > > about source repo.
>> > > >
>> > > >
>> > > > > -Deng
>> > > > >
>> > > > > On Mon, May 31, 2010 at 3:29 PM, Deng Ching <oc...@apache.org>
>> > wrote:
>> > > > >
>> > > > > > Hi Eshan,
>> > > > > >
>> > > > > > Can you attach/add the images to the wiki page so we can relate
>> it
>> > to
>> > > > the
>> > > > > > specific proposal?
>> > > > > > Btw, I agree with what Brett said.. you shouldn't be reading the
>> > > > metadata
>> > > > > > to get the artifacts in the source repository.
>> > > > > >
>> > > > > > -Deng
>> > > > > >
>> > > > > > On Mon, May 31, 2010 at 11:52 AM, Eshan Sudharaka <
>> > > > esudharaka@gmail.com
>> > > > > >wrote:
>> > > > > >
>> > > > > >> On Mon, May 31, 2010 at 9:19 AM, Eshan Sudharaka <
>> > > > esudharaka@gmail.com
>> > > > > >> >wrote:
>> > > > > >>
>> > > > > >> > <metadata>
>> > > > > >> > <groupId>log4j</groupId>
>> > > > > >> > <artifactId>log4j</artifactId>
>> > > > > >> > <versioning>
>> > > > > >> > <latest>1.2.14</latest>
>> > > > > >> > <release>1.2.14</release>
>> > > > > >> > <versions>
>> > > > > >> > <version>1.2.8</version>
>> > > > > >> > <version>1.2.14</version>
>> > > > > >> > </versions>
>> > > > > >> > </versioning>
>> > > > > >> > </metadata>
>> > > > > >> > by reading this files we can get the list of available
>> > artifacts
>> > > in
>> > > > > the
>> > > > > >> > source repo. Then we can do differeent actions for merging
>> for
>> > > > > following
>> > > > > >> > cases.
>> > > > > >> > * there is a same artifact in target repo
>> > > > > >> > * no such artifact in target repo
>> > > > > >> >
>> > > > > >> > On Sun, May 30, 2010 at 12:13 PM, Brett Porter <
>> > brett@apache.org>
>> > > > > >> wrote:
>> > > > > >> >
>> > > > > >> >> The image was missing (this list would strip attachments).
>> > Maybe
>> > > > you
>> > > > > >> can
>> > > > > >> >> post it to the wiki?
>> > > > > >> >>
>> > > > > >> >
>> > > > > >> > il send the link.
>> > > > > >> >
>> > > > > >> >>
>> > > > > >> >>
>> > > > > >>
>> > > > >
>> > > >
>> > >
>> >
>> http://picasaweb.google.com/104163866911029090831/ClassDiagrams#5477276612723378274
>> > > > > >> >> As for existing tools - the repository scanner is what
>> > traverses
>> > > > the
>> > > > > >> >> folder structure, but I'm unsure why you need to do that for
>> > the
>> > > > > >> metadata
>> > > > > >> >> files - the mechanism should be artifact centric and the
>> > metadata
>> > > > > files
>> > > > > >> just
>> > > > > >> >> go along with them.
>> > > > > >> >>
>> > > > > >> >> - Brett
>> > > > > >> >>
>> > > > > >> >> On 28/05/2010, at 7:37 PM, Eshan Sudharaka wrote:
>> > > > > >> >>
>> > > > > >> >> > here i have attached the basic structure of the class.
>> And i
>> > > > want
>> > > > > to
>> > > > > >> >> know do i need to implement a search method to iterate
>> through
>> > > the
>> > > > > >> folder
>> > > > > >> >> structure and find the maven meta data XML files ? or that
>> > > > > >> functionality is
>> > > > > >> >> al;ready there in archiva code base ?
>> > > > > >> >> >
>> > > > > >> >> > --
>> > > > > >> >> > 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
>> > > > > >> >
>> > > > > >>
>> > > > > >>
>> > > > > >>
>> > > > > >> --
>> > > > > >> 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
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > 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
>
--
P.A.Eshan Sudharaka
Dept of Computer Science and Engineering
University of Moratuwa
Sri Lanka
Re: design for sourceArtifactDetails class
Posted by Eshan Sudharaka <es...@gmail.com>.
is there a way to get the meta data repo for a particula repo. as i
understood we can get all details of the repository by using itz meta data
repository. (i follwed the DefaultMetadataResolver class.)
On Wed, Jun 2, 2010 at 2:24 PM, Deng Ching <oc...@apache.org> wrote:
> Did you check the MetadataResolver class? I think you can get the artifacts
> in the repository from there.. :)
>
> -Deng
>
> On Wed, Jun 2, 2010 at 4:48 PM, Eshan Sudharaka <esudharaka@gmail.com
> >wrote:
>
> > On Wed, Jun 2, 2010 at 12:17 PM, Deng Ching <oc...@apache.org> wrote:
> >
> > > In that case, I don't think you'd need the readMetadata(..) method?
> >
> > here i am confusing. how do we know what are the avialable artifacts is
> > the
> > repository with out reading the maven meta data xml file..? my approach
> was
> > to get the list of available artifacts in the source repo by reading the
> > maven meta data xml file. then i am going to pass the maven meta data
> xml
> > file to read (by using archiva existing class).So i need to find a way
> to
> > search the maven meta data file(location). So it can be implemented in
> > another class.
> >
> >
> > > As for
> > > the searchRepo(..) method, I think this should be moved out of the
> class
> > > into a separate one since it is not specific for the source repository,
> > but
> > > rather to the target repository.
> > >
> > >
> >
> > > It would also be good to change the name of the class to make it more
> > > descriptive of what it intends to do..
> > >
> > > Thanks,
> > > Deng
> > >
> > > On Tue, Jun 1, 2010 at 2:03 PM, Eshan Sudharaka <esudharaka@gmail.com
> > > >wrote:
> > >
> > > > On Tue, Jun 1, 2010 at 11:20 AM, Deng Ching <oc...@apache.org>
> wrote:
> > > >
> > > > > Thanks for attaching the diagram in the wiki page :)
> > > > >
> > > > > Right now, I'm not sure what the SourceArtifactDetails is
> > specifically
> > > > for.
> > > > > From the last diagram you sent in the previous thread (
> > > > >
> > > > >
> > > >
> > >
> >
> http://old.nabble.com/procedure-for-the-stage-repo-merge-implementation-td28647541.html
> > > > > ),
> > > > > I thought it was for a source artifact. But now, it looks like it's
> > > > > specifically for the source repository?
> > > > >
> > > > > ya. It gather information of source repository that we are going
> > to
> > > > mearge. once we have a source artifact list then we can search
> through
> > > the
> > > > destination repository and copy them.
> > > >
> > > > since i am going to introduce both replacing(for available artifact
> in
> > > > target repo) and copying i thought it is better to gather
> information
> > > > about source repo.
> > > >
> > > >
> > > > > -Deng
> > > > >
> > > > > On Mon, May 31, 2010 at 3:29 PM, Deng Ching <oc...@apache.org>
> > wrote:
> > > > >
> > > > > > Hi Eshan,
> > > > > >
> > > > > > Can you attach/add the images to the wiki page so we can relate
> it
> > to
> > > > the
> > > > > > specific proposal?
> > > > > > Btw, I agree with what Brett said.. you shouldn't be reading the
> > > > metadata
> > > > > > to get the artifacts in the source repository.
> > > > > >
> > > > > > -Deng
> > > > > >
> > > > > > On Mon, May 31, 2010 at 11:52 AM, Eshan Sudharaka <
> > > > esudharaka@gmail.com
> > > > > >wrote:
> > > > > >
> > > > > >> On Mon, May 31, 2010 at 9:19 AM, Eshan Sudharaka <
> > > > esudharaka@gmail.com
> > > > > >> >wrote:
> > > > > >>
> > > > > >> > <metadata>
> > > > > >> > <groupId>log4j</groupId>
> > > > > >> > <artifactId>log4j</artifactId>
> > > > > >> > <versioning>
> > > > > >> > <latest>1.2.14</latest>
> > > > > >> > <release>1.2.14</release>
> > > > > >> > <versions>
> > > > > >> > <version>1.2.8</version>
> > > > > >> > <version>1.2.14</version>
> > > > > >> > </versions>
> > > > > >> > </versioning>
> > > > > >> > </metadata>
> > > > > >> > by reading this files we can get the list of available
> > artifacts
> > > in
> > > > > the
> > > > > >> > source repo. Then we can do differeent actions for merging for
> > > > > following
> > > > > >> > cases.
> > > > > >> > * there is a same artifact in target repo
> > > > > >> > * no such artifact in target repo
> > > > > >> >
> > > > > >> > On Sun, May 30, 2010 at 12:13 PM, Brett Porter <
> > brett@apache.org>
> > > > > >> wrote:
> > > > > >> >
> > > > > >> >> The image was missing (this list would strip attachments).
> > Maybe
> > > > you
> > > > > >> can
> > > > > >> >> post it to the wiki?
> > > > > >> >>
> > > > > >> >
> > > > > >> > il send the link.
> > > > > >> >
> > > > > >> >>
> > > > > >> >>
> > > > > >>
> > > > >
> > > >
> > >
> >
> http://picasaweb.google.com/104163866911029090831/ClassDiagrams#5477276612723378274
> > > > > >> >> As for existing tools - the repository scanner is what
> > traverses
> > > > the
> > > > > >> >> folder structure, but I'm unsure why you need to do that for
> > the
> > > > > >> metadata
> > > > > >> >> files - the mechanism should be artifact centric and the
> > metadata
> > > > > files
> > > > > >> just
> > > > > >> >> go along with them.
> > > > > >> >>
> > > > > >> >> - Brett
> > > > > >> >>
> > > > > >> >> On 28/05/2010, at 7:37 PM, Eshan Sudharaka wrote:
> > > > > >> >>
> > > > > >> >> > here i have attached the basic structure of the class. And
> i
> > > > want
> > > > > to
> > > > > >> >> know do i need to implement a search method to iterate
> through
> > > the
> > > > > >> folder
> > > > > >> >> structure and find the maven meta data XML files ? or that
> > > > > >> functionality is
> > > > > >> >> al;ready there in archiva code base ?
> > > > > >> >> >
> > > > > >> >> > --
> > > > > >> >> > 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
> > > > > >> >
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> 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
> > > >
> > >
> >
> >
> >
> > --
> > 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: design for sourceArtifactDetails class
Posted by Deng Ching <oc...@apache.org>.
Did you check the MetadataResolver class? I think you can get the artifacts
in the repository from there.. :)
-Deng
On Wed, Jun 2, 2010 at 4:48 PM, Eshan Sudharaka <es...@gmail.com>wrote:
> On Wed, Jun 2, 2010 at 12:17 PM, Deng Ching <oc...@apache.org> wrote:
>
> > In that case, I don't think you'd need the readMetadata(..) method?
>
> here i am confusing. how do we know what are the avialable artifacts is
> the
> repository with out reading the maven meta data xml file..? my approach was
> to get the list of available artifacts in the source repo by reading the
> maven meta data xml file. then i am going to pass the maven meta data xml
> file to read (by using archiva existing class).So i need to find a way to
> search the maven meta data file(location). So it can be implemented in
> another class.
>
>
> > As for
> > the searchRepo(..) method, I think this should be moved out of the class
> > into a separate one since it is not specific for the source repository,
> but
> > rather to the target repository.
> >
> >
>
> > It would also be good to change the name of the class to make it more
> > descriptive of what it intends to do..
> >
> > Thanks,
> > Deng
> >
> > On Tue, Jun 1, 2010 at 2:03 PM, Eshan Sudharaka <esudharaka@gmail.com
> > >wrote:
> >
> > > On Tue, Jun 1, 2010 at 11:20 AM, Deng Ching <oc...@apache.org> wrote:
> > >
> > > > Thanks for attaching the diagram in the wiki page :)
> > > >
> > > > Right now, I'm not sure what the SourceArtifactDetails is
> specifically
> > > for.
> > > > From the last diagram you sent in the previous thread (
> > > >
> > > >
> > >
> >
> http://old.nabble.com/procedure-for-the-stage-repo-merge-implementation-td28647541.html
> > > > ),
> > > > I thought it was for a source artifact. But now, it looks like it's
> > > > specifically for the source repository?
> > > >
> > > > ya. It gather information of source repository that we are going
> to
> > > mearge. once we have a source artifact list then we can search through
> > the
> > > destination repository and copy them.
> > >
> > > since i am going to introduce both replacing(for available artifact in
> > > target repo) and copying i thought it is better to gather information
> > > about source repo.
> > >
> > >
> > > > -Deng
> > > >
> > > > On Mon, May 31, 2010 at 3:29 PM, Deng Ching <oc...@apache.org>
> wrote:
> > > >
> > > > > Hi Eshan,
> > > > >
> > > > > Can you attach/add the images to the wiki page so we can relate it
> to
> > > the
> > > > > specific proposal?
> > > > > Btw, I agree with what Brett said.. you shouldn't be reading the
> > > metadata
> > > > > to get the artifacts in the source repository.
> > > > >
> > > > > -Deng
> > > > >
> > > > > On Mon, May 31, 2010 at 11:52 AM, Eshan Sudharaka <
> > > esudharaka@gmail.com
> > > > >wrote:
> > > > >
> > > > >> On Mon, May 31, 2010 at 9:19 AM, Eshan Sudharaka <
> > > esudharaka@gmail.com
> > > > >> >wrote:
> > > > >>
> > > > >> > <metadata>
> > > > >> > <groupId>log4j</groupId>
> > > > >> > <artifactId>log4j</artifactId>
> > > > >> > <versioning>
> > > > >> > <latest>1.2.14</latest>
> > > > >> > <release>1.2.14</release>
> > > > >> > <versions>
> > > > >> > <version>1.2.8</version>
> > > > >> > <version>1.2.14</version>
> > > > >> > </versions>
> > > > >> > </versioning>
> > > > >> > </metadata>
> > > > >> > by reading this files we can get the list of available
> artifacts
> > in
> > > > the
> > > > >> > source repo. Then we can do differeent actions for merging for
> > > > following
> > > > >> > cases.
> > > > >> > * there is a same artifact in target repo
> > > > >> > * no such artifact in target repo
> > > > >> >
> > > > >> > On Sun, May 30, 2010 at 12:13 PM, Brett Porter <
> brett@apache.org>
> > > > >> wrote:
> > > > >> >
> > > > >> >> The image was missing (this list would strip attachments).
> Maybe
> > > you
> > > > >> can
> > > > >> >> post it to the wiki?
> > > > >> >>
> > > > >> >
> > > > >> > il send the link.
> > > > >> >
> > > > >> >>
> > > > >> >>
> > > > >>
> > > >
> > >
> >
> http://picasaweb.google.com/104163866911029090831/ClassDiagrams#5477276612723378274
> > > > >> >> As for existing tools - the repository scanner is what
> traverses
> > > the
> > > > >> >> folder structure, but I'm unsure why you need to do that for
> the
> > > > >> metadata
> > > > >> >> files - the mechanism should be artifact centric and the
> metadata
> > > > files
> > > > >> just
> > > > >> >> go along with them.
> > > > >> >>
> > > > >> >> - Brett
> > > > >> >>
> > > > >> >> On 28/05/2010, at 7:37 PM, Eshan Sudharaka wrote:
> > > > >> >>
> > > > >> >> > here i have attached the basic structure of the class. And i
> > > want
> > > > to
> > > > >> >> know do i need to implement a search method to iterate through
> > the
> > > > >> folder
> > > > >> >> structure and find the maven meta data XML files ? or that
> > > > >> functionality is
> > > > >> >> al;ready there in archiva code base ?
> > > > >> >> >
> > > > >> >> > --
> > > > >> >> > 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
> > > > >> >
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> 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
> > >
> >
>
>
>
> --
> P.A.Eshan Sudharaka
> Dept of Computer Science and Engineering
> University of Moratuwa
> Sri Lanka
>
Re: design for sourceArtifactDetails class
Posted by Eshan Sudharaka <es...@gmail.com>.
On Wed, Jun 2, 2010 at 12:17 PM, Deng Ching <oc...@apache.org> wrote:
> In that case, I don't think you'd need the readMetadata(..) method?
here i am confusing. how do we know what are the avialable artifacts is the
repository with out reading the maven meta data xml file..? my approach was
to get the list of available artifacts in the source repo by reading the
maven meta data xml file. then i am going to pass the maven meta data xml
file to read (by using archiva existing class).So i need to find a way to
search the maven meta data file(location). So it can be implemented in
another class.
> As for
> the searchRepo(..) method, I think this should be moved out of the class
> into a separate one since it is not specific for the source repository, but
> rather to the target repository.
>
>
> It would also be good to change the name of the class to make it more
> descriptive of what it intends to do..
>
> Thanks,
> Deng
>
> On Tue, Jun 1, 2010 at 2:03 PM, Eshan Sudharaka <esudharaka@gmail.com
> >wrote:
>
> > On Tue, Jun 1, 2010 at 11:20 AM, Deng Ching <oc...@apache.org> wrote:
> >
> > > Thanks for attaching the diagram in the wiki page :)
> > >
> > > Right now, I'm not sure what the SourceArtifactDetails is specifically
> > for.
> > > From the last diagram you sent in the previous thread (
> > >
> > >
> >
> http://old.nabble.com/procedure-for-the-stage-repo-merge-implementation-td28647541.html
> > > ),
> > > I thought it was for a source artifact. But now, it looks like it's
> > > specifically for the source repository?
> > >
> > > ya. It gather information of source repository that we are going to
> > mearge. once we have a source artifact list then we can search through
> the
> > destination repository and copy them.
> >
> > since i am going to introduce both replacing(for available artifact in
> > target repo) and copying i thought it is better to gather information
> > about source repo.
> >
> >
> > > -Deng
> > >
> > > On Mon, May 31, 2010 at 3:29 PM, Deng Ching <oc...@apache.org> wrote:
> > >
> > > > Hi Eshan,
> > > >
> > > > Can you attach/add the images to the wiki page so we can relate it to
> > the
> > > > specific proposal?
> > > > Btw, I agree with what Brett said.. you shouldn't be reading the
> > metadata
> > > > to get the artifacts in the source repository.
> > > >
> > > > -Deng
> > > >
> > > > On Mon, May 31, 2010 at 11:52 AM, Eshan Sudharaka <
> > esudharaka@gmail.com
> > > >wrote:
> > > >
> > > >> On Mon, May 31, 2010 at 9:19 AM, Eshan Sudharaka <
> > esudharaka@gmail.com
> > > >> >wrote:
> > > >>
> > > >> > <metadata>
> > > >> > <groupId>log4j</groupId>
> > > >> > <artifactId>log4j</artifactId>
> > > >> > <versioning>
> > > >> > <latest>1.2.14</latest>
> > > >> > <release>1.2.14</release>
> > > >> > <versions>
> > > >> > <version>1.2.8</version>
> > > >> > <version>1.2.14</version>
> > > >> > </versions>
> > > >> > </versioning>
> > > >> > </metadata>
> > > >> > by reading this files we can get the list of available artifacts
> in
> > > the
> > > >> > source repo. Then we can do differeent actions for merging for
> > > following
> > > >> > cases.
> > > >> > * there is a same artifact in target repo
> > > >> > * no such artifact in target repo
> > > >> >
> > > >> > On Sun, May 30, 2010 at 12:13 PM, Brett Porter <br...@apache.org>
> > > >> wrote:
> > > >> >
> > > >> >> The image was missing (this list would strip attachments). Maybe
> > you
> > > >> can
> > > >> >> post it to the wiki?
> > > >> >>
> > > >> >
> > > >> > il send the link.
> > > >> >
> > > >> >>
> > > >> >>
> > > >>
> > >
> >
> http://picasaweb.google.com/104163866911029090831/ClassDiagrams#5477276612723378274
> > > >> >> As for existing tools - the repository scanner is what traverses
> > the
> > > >> >> folder structure, but I'm unsure why you need to do that for the
> > > >> metadata
> > > >> >> files - the mechanism should be artifact centric and the metadata
> > > files
> > > >> just
> > > >> >> go along with them.
> > > >> >>
> > > >> >> - Brett
> > > >> >>
> > > >> >> On 28/05/2010, at 7:37 PM, Eshan Sudharaka wrote:
> > > >> >>
> > > >> >> > here i have attached the basic structure of the class. And i
> > want
> > > to
> > > >> >> know do i need to implement a search method to iterate through
> the
> > > >> folder
> > > >> >> structure and find the maven meta data XML files ? or that
> > > >> functionality is
> > > >> >> al;ready there in archiva code base ?
> > > >> >> >
> > > >> >> > --
> > > >> >> > 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
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> 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
> >
>
--
P.A.Eshan Sudharaka
Dept of Computer Science and Engineering
University of Moratuwa
Sri Lanka
Re: design for sourceArtifactDetails class
Posted by Deng Ching <oc...@apache.org>.
In that case, I don't think you'd need the readMetadata(..) method? As for
the searchRepo(..) method, I think this should be moved out of the class
into a separate one since it is not specific for the source repository, but
rather to the target repository.
It would also be good to change the name of the class to make it more
descriptive of what it intends to do..
Thanks,
Deng
On Tue, Jun 1, 2010 at 2:03 PM, Eshan Sudharaka <es...@gmail.com>wrote:
> On Tue, Jun 1, 2010 at 11:20 AM, Deng Ching <oc...@apache.org> wrote:
>
> > Thanks for attaching the diagram in the wiki page :)
> >
> > Right now, I'm not sure what the SourceArtifactDetails is specifically
> for.
> > From the last diagram you sent in the previous thread (
> >
> >
> http://old.nabble.com/procedure-for-the-stage-repo-merge-implementation-td28647541.html
> > ),
> > I thought it was for a source artifact. But now, it looks like it's
> > specifically for the source repository?
> >
> > ya. It gather information of source repository that we are going to
> mearge. once we have a source artifact list then we can search through the
> destination repository and copy them.
>
> since i am going to introduce both replacing(for available artifact in
> target repo) and copying i thought it is better to gather information
> about source repo.
>
>
> > -Deng
> >
> > On Mon, May 31, 2010 at 3:29 PM, Deng Ching <oc...@apache.org> wrote:
> >
> > > Hi Eshan,
> > >
> > > Can you attach/add the images to the wiki page so we can relate it to
> the
> > > specific proposal?
> > > Btw, I agree with what Brett said.. you shouldn't be reading the
> metadata
> > > to get the artifacts in the source repository.
> > >
> > > -Deng
> > >
> > > On Mon, May 31, 2010 at 11:52 AM, Eshan Sudharaka <
> esudharaka@gmail.com
> > >wrote:
> > >
> > >> On Mon, May 31, 2010 at 9:19 AM, Eshan Sudharaka <
> esudharaka@gmail.com
> > >> >wrote:
> > >>
> > >> > <metadata>
> > >> > <groupId>log4j</groupId>
> > >> > <artifactId>log4j</artifactId>
> > >> > <versioning>
> > >> > <latest>1.2.14</latest>
> > >> > <release>1.2.14</release>
> > >> > <versions>
> > >> > <version>1.2.8</version>
> > >> > <version>1.2.14</version>
> > >> > </versions>
> > >> > </versioning>
> > >> > </metadata>
> > >> > by reading this files we can get the list of available artifacts in
> > the
> > >> > source repo. Then we can do differeent actions for merging for
> > following
> > >> > cases.
> > >> > * there is a same artifact in target repo
> > >> > * no such artifact in target repo
> > >> >
> > >> > On Sun, May 30, 2010 at 12:13 PM, Brett Porter <br...@apache.org>
> > >> wrote:
> > >> >
> > >> >> The image was missing (this list would strip attachments). Maybe
> you
> > >> can
> > >> >> post it to the wiki?
> > >> >>
> > >> >
> > >> > il send the link.
> > >> >
> > >> >>
> > >> >>
> > >>
> >
> http://picasaweb.google.com/104163866911029090831/ClassDiagrams#5477276612723378274
> > >> >> As for existing tools - the repository scanner is what traverses
> the
> > >> >> folder structure, but I'm unsure why you need to do that for the
> > >> metadata
> > >> >> files - the mechanism should be artifact centric and the metadata
> > files
> > >> just
> > >> >> go along with them.
> > >> >>
> > >> >> - Brett
> > >> >>
> > >> >> On 28/05/2010, at 7:37 PM, Eshan Sudharaka wrote:
> > >> >>
> > >> >> > here i have attached the basic structure of the class. And i
> want
> > to
> > >> >> know do i need to implement a search method to iterate through the
> > >> folder
> > >> >> structure and find the maven meta data XML files ? or that
> > >> functionality is
> > >> >> al;ready there in archiva code base ?
> > >> >> >
> > >> >> > --
> > >> >> > 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
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> 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: design for sourceArtifactDetails class
Posted by Eshan Sudharaka <es...@gmail.com>.
On Tue, Jun 1, 2010 at 11:20 AM, Deng Ching <oc...@apache.org> wrote:
> Thanks for attaching the diagram in the wiki page :)
>
> Right now, I'm not sure what the SourceArtifactDetails is specifically for.
> From the last diagram you sent in the previous thread (
>
> http://old.nabble.com/procedure-for-the-stage-repo-merge-implementation-td28647541.html
> ),
> I thought it was for a source artifact. But now, it looks like it's
> specifically for the source repository?
>
> ya. It gather information of source repository that we are going to
mearge. once we have a source artifact list then we can search through the
destination repository and copy them.
since i am going to introduce both replacing(for available artifact in
target repo) and copying i thought it is better to gather information
about source repo.
> -Deng
>
> On Mon, May 31, 2010 at 3:29 PM, Deng Ching <oc...@apache.org> wrote:
>
> > Hi Eshan,
> >
> > Can you attach/add the images to the wiki page so we can relate it to the
> > specific proposal?
> > Btw, I agree with what Brett said.. you shouldn't be reading the metadata
> > to get the artifacts in the source repository.
> >
> > -Deng
> >
> > On Mon, May 31, 2010 at 11:52 AM, Eshan Sudharaka <esudharaka@gmail.com
> >wrote:
> >
> >> On Mon, May 31, 2010 at 9:19 AM, Eshan Sudharaka <esudharaka@gmail.com
> >> >wrote:
> >>
> >> > <metadata>
> >> > <groupId>log4j</groupId>
> >> > <artifactId>log4j</artifactId>
> >> > <versioning>
> >> > <latest>1.2.14</latest>
> >> > <release>1.2.14</release>
> >> > <versions>
> >> > <version>1.2.8</version>
> >> > <version>1.2.14</version>
> >> > </versions>
> >> > </versioning>
> >> > </metadata>
> >> > by reading this files we can get the list of available artifacts in
> the
> >> > source repo. Then we can do differeent actions for merging for
> following
> >> > cases.
> >> > * there is a same artifact in target repo
> >> > * no such artifact in target repo
> >> >
> >> > On Sun, May 30, 2010 at 12:13 PM, Brett Porter <br...@apache.org>
> >> wrote:
> >> >
> >> >> The image was missing (this list would strip attachments). Maybe you
> >> can
> >> >> post it to the wiki?
> >> >>
> >> >
> >> > il send the link.
> >> >
> >> >>
> >> >>
> >>
> http://picasaweb.google.com/104163866911029090831/ClassDiagrams#5477276612723378274
> >> >> As for existing tools - the repository scanner is what traverses the
> >> >> folder structure, but I'm unsure why you need to do that for the
> >> metadata
> >> >> files - the mechanism should be artifact centric and the metadata
> files
> >> just
> >> >> go along with them.
> >> >>
> >> >> - Brett
> >> >>
> >> >> On 28/05/2010, at 7:37 PM, Eshan Sudharaka wrote:
> >> >>
> >> >> > here i have attached the basic structure of the class. And i want
> to
> >> >> know do i need to implement a search method to iterate through the
> >> folder
> >> >> structure and find the maven meta data XML files ? or that
> >> functionality is
> >> >> al;ready there in archiva code base ?
> >> >> >
> >> >> > --
> >> >> > 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
> >> >
> >>
> >>
> >>
> >> --
> >> 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: design for sourceArtifactDetails class
Posted by Deng Ching <oc...@apache.org>.
Thanks for attaching the diagram in the wiki page :)
Right now, I'm not sure what the SourceArtifactDetails is specifically for.
>From the last diagram you sent in the previous thread (
http://old.nabble.com/procedure-for-the-stage-repo-merge-implementation-td28647541.html),
I thought it was for a source artifact. But now, it looks like it's
specifically for the source repository?
-Deng
On Mon, May 31, 2010 at 3:29 PM, Deng Ching <oc...@apache.org> wrote:
> Hi Eshan,
>
> Can you attach/add the images to the wiki page so we can relate it to the
> specific proposal?
> Btw, I agree with what Brett said.. you shouldn't be reading the metadata
> to get the artifacts in the source repository.
>
> -Deng
>
> On Mon, May 31, 2010 at 11:52 AM, Eshan Sudharaka <es...@gmail.com>wrote:
>
>> On Mon, May 31, 2010 at 9:19 AM, Eshan Sudharaka <esudharaka@gmail.com
>> >wrote:
>>
>> > <metadata>
>> > <groupId>log4j</groupId>
>> > <artifactId>log4j</artifactId>
>> > <versioning>
>> > <latest>1.2.14</latest>
>> > <release>1.2.14</release>
>> > <versions>
>> > <version>1.2.8</version>
>> > <version>1.2.14</version>
>> > </versions>
>> > </versioning>
>> > </metadata>
>> > by reading this files we can get the list of available artifacts in the
>> > source repo. Then we can do differeent actions for merging for following
>> > cases.
>> > * there is a same artifact in target repo
>> > * no such artifact in target repo
>> >
>> > On Sun, May 30, 2010 at 12:13 PM, Brett Porter <br...@apache.org>
>> wrote:
>> >
>> >> The image was missing (this list would strip attachments). Maybe you
>> can
>> >> post it to the wiki?
>> >>
>> >
>> > il send the link.
>> >
>> >>
>> >>
>> http://picasaweb.google.com/104163866911029090831/ClassDiagrams#5477276612723378274
>> >> As for existing tools - the repository scanner is what traverses the
>> >> folder structure, but I'm unsure why you need to do that for the
>> metadata
>> >> files - the mechanism should be artifact centric and the metadata files
>> just
>> >> go along with them.
>> >>
>> >> - Brett
>> >>
>> >> On 28/05/2010, at 7:37 PM, Eshan Sudharaka wrote:
>> >>
>> >> > here i have attached the basic structure of the class. And i want to
>> >> know do i need to implement a search method to iterate through the
>> folder
>> >> structure and find the maven meta data XML files ? or that
>> functionality is
>> >> al;ready there in archiva code base ?
>> >> >
>> >> > --
>> >> > 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
>> >
>>
>>
>>
>> --
>> P.A.Eshan Sudharaka
>> Dept of Computer Science and Engineering
>> University of Moratuwa
>> Sri Lanka
>>
>
>
Re: design for sourceArtifactDetails class
Posted by Deng Ching <oc...@apache.org>.
Hi Eshan,
Can you attach/add the images to the wiki page so we can relate it to the
specific proposal?
Btw, I agree with what Brett said.. you shouldn't be reading the metadata to
get the artifacts in the source repository.
-Deng
On Mon, May 31, 2010 at 11:52 AM, Eshan Sudharaka <es...@gmail.com>wrote:
> On Mon, May 31, 2010 at 9:19 AM, Eshan Sudharaka <esudharaka@gmail.com
> >wrote:
>
> > <metadata>
> > <groupId>log4j</groupId>
> > <artifactId>log4j</artifactId>
> > <versioning>
> > <latest>1.2.14</latest>
> > <release>1.2.14</release>
> > <versions>
> > <version>1.2.8</version>
> > <version>1.2.14</version>
> > </versions>
> > </versioning>
> > </metadata>
> > by reading this files we can get the list of available artifacts in the
> > source repo. Then we can do differeent actions for merging for following
> > cases.
> > * there is a same artifact in target repo
> > * no such artifact in target repo
> >
> > On Sun, May 30, 2010 at 12:13 PM, Brett Porter <br...@apache.org> wrote:
> >
> >> The image was missing (this list would strip attachments). Maybe you can
> >> post it to the wiki?
> >>
> >
> > il send the link.
> >
> >>
> >>
> http://picasaweb.google.com/104163866911029090831/ClassDiagrams#5477276612723378274
> >> As for existing tools - the repository scanner is what traverses the
> >> folder structure, but I'm unsure why you need to do that for the
> metadata
> >> files - the mechanism should be artifact centric and the metadata files
> just
> >> go along with them.
> >>
> >> - Brett
> >>
> >> On 28/05/2010, at 7:37 PM, Eshan Sudharaka wrote:
> >>
> >> > here i have attached the basic structure of the class. And i want to
> >> know do i need to implement a search method to iterate through the
> folder
> >> structure and find the maven meta data XML files ? or that functionality
> is
> >> al;ready there in archiva code base ?
> >> >
> >> > --
> >> > 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
> >
>
>
>
> --
> P.A.Eshan Sudharaka
> Dept of Computer Science and Engineering
> University of Moratuwa
> Sri Lanka
>
Re: design for sourceArtifactDetails class
Posted by Eshan Sudharaka <es...@gmail.com>.
On Mon, May 31, 2010 at 9:19 AM, Eshan Sudharaka <es...@gmail.com>wrote:
> <metadata>
> <groupId>log4j</groupId>
> <artifactId>log4j</artifactId>
> <versioning>
> <latest>1.2.14</latest>
> <release>1.2.14</release>
> <versions>
> <version>1.2.8</version>
> <version>1.2.14</version>
> </versions>
> </versioning>
> </metadata>
> by reading this files we can get the list of available artifacts in the
> source repo. Then we can do differeent actions for merging for following
> cases.
> * there is a same artifact in target repo
> * no such artifact in target repo
>
> On Sun, May 30, 2010 at 12:13 PM, Brett Porter <br...@apache.org> wrote:
>
>> The image was missing (this list would strip attachments). Maybe you can
>> post it to the wiki?
>>
>
> il send the link.
>
>>
>> http://picasaweb.google.com/104163866911029090831/ClassDiagrams#5477276612723378274
>> As for existing tools - the repository scanner is what traverses the
>> folder structure, but I'm unsure why you need to do that for the metadata
>> files - the mechanism should be artifact centric and the metadata files just
>> go along with them.
>>
>> - Brett
>>
>> On 28/05/2010, at 7:37 PM, Eshan Sudharaka wrote:
>>
>> > here i have attached the basic structure of the class. And i want to
>> know do i need to implement a search method to iterate through the folder
>> structure and find the maven meta data XML files ? or that functionality is
>> al;ready there in archiva code base ?
>> >
>> > --
>> > 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
>
--
P.A.Eshan Sudharaka
Dept of Computer Science and Engineering
University of Moratuwa
Sri Lanka
Re: design for sourceArtifactDetails class
Posted by Eshan Sudharaka <es...@gmail.com>.
<metadata>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<versioning>
<latest>1.2.14</latest>
<release>1.2.14</release>
<versions>
<version>1.2.8</version>
<version>1.2.14</version>
</versions>
</versioning>
</metadata>
by reading this files we can get the list of available artifacts in the
source repo. Then we can do differeent actions for merging for following
cases.
* there is a same artifact in target repo
* no such artifact in target repo
On Sun, May 30, 2010 at 12:13 PM, Brett Porter <br...@apache.org> wrote:
> The image was missing (this list would strip attachments). Maybe you can
> post it to the wiki?
>
il send the link.
>
> As for existing tools - the repository scanner is what traverses the folder
> structure, but I'm unsure why you need to do that for the metadata files -
> the mechanism should be artifact centric and the metadata files just go
> along with them.
>
> - Brett
>
> On 28/05/2010, at 7:37 PM, Eshan Sudharaka wrote:
>
> > here i have attached the basic structure of the class. And i want to
> know do i need to implement a search method to iterate through the folder
> structure and find the maven meta data XML files ? or that functionality is
> al;ready there in archiva code base ?
> >
> > --
> > 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: design for sourceArtifactDetails class
Posted by Brett Porter <br...@apache.org>.
The image was missing (this list would strip attachments). Maybe you can post it to the wiki?
As for existing tools - the repository scanner is what traverses the folder structure, but I'm unsure why you need to do that for the metadata files - the mechanism should be artifact centric and the metadata files just go along with them.
- Brett
On 28/05/2010, at 7:37 PM, Eshan Sudharaka wrote:
> here i have attached the basic structure of the class. And i want to know do i need to implement a search method to iterate through the folder structure and find the maven meta data XML files ? or that functionality is al;ready there in archiva code base ?
>
> --
> P.A.Eshan Sudharaka
> Dept of Computer Science and Engineering
> University of Moratuwa
> Sri Lanka