archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "nicolas de loof" <nico...@apache.org>
Subject Re: wrong metadatas
Date Thu, 10 Jul 2008 09:13:54 GMT
This mean the First metadata file found in on repo of the group is returned
!

This is what happen : I get a metadat file with no <version> included (not
an blank file, but an XML construct with just root element) : this is the
content of my first repo in the group, that did not retrieve the expected
artifact.

I made a simple test : place "release" repo before "corporate" in the group,
and I the get the expected metadata.

My conclusion is we have two options :

- support metadata merge from repositories in the group (not just "first
win")
- don't create metadata in managed repo if no artifact was found from
proxies.





2008/7/10 Maria Odea Ching <oching@apache.org>:

> The ArchivaVirtualDavResource is for the dav browse (directories), not for
> artifact requests..
>
> Hmm, the virtual repos work this way:
> - client requests for an artifact
> - RepoServlet handles the request and goes to ArchivaDavSessionProvider
> - in ArchivaDavSessionProvider, the request is checked if it is a repo
> group
> url or a regular repo url.
>   If it is, then loop through the repos under the group. The first
> requested artifact found among the repos
>   is returned (proxied or already existing). The metadata update/merge
> happens when the artifact is
>   fetched from the proxies (but this is on a per repository level, there's
> no metadata of metadata files
>   from each repo being merged at the repo group level)
>
> The same process goes if the request made is for a metadata file. I don't
> know why a blank metadata file was returned.. :(
>
> Thanks,
> Deng
>
> On Thu, Jul 10, 2008 at 3:39 PM, nicolas de loof <nicolas@apache.org>
> wrote:
>
> > I just started investigating on this. I can't find where the metadatas
> are
> > merged when a repository group is set. From my understanding,
> > ArchivaVirtualDavResource is used with a List<File> of metadatas from
> each
> > repo in the group. But I don't find WHERE the metadata files are merged
> > into
> > a single XML content...
> >
> >
> >
> > 2008/7/10 Maria Odea Ching <oching@exist.com>:
> >
> > > Ok, thanks Nico, Dan :)
> > > I'll look into this further.. I guess we could include this in 1.1.1
> > which
> > > is scheduled to be released right after 1.1 to fix another blocker in
> > 1.1.
> > >
> > > Thanks,
> > > Deng
> > >
> > > On Thu, Jul 10, 2008 at 2:37 PM, nicolas de loof <nicolas@apache.org>
> > > wrote:
> > >
> > > > MRM-872 created for this, with the concrete case I fall into.
> > > >
> > > > If confirmed, this is a blocker for repository group use
> > > >
> > > > 2008/7/10 Dan Tran <dantran@gmail.com>:
> > > >
> > > > > sounds like  a blocking bug? would love to see this fixed in 1.1
> :-)
> > > > >
> > > > > On Wed, Jul 9, 2008 at 7:11 PM, Maria Odea Ching <
> oching@apache.org>
> > > > > wrote:
> > > > > > Hi Nico,
> > > > > >
> > > > > > That looks like a new bug :( The metadata should be just the
same
> > as
> > > > the
> > > > > > regular metadata of a managed repo (not belonging to a group)
as
> it
> > > > uses
> > > > > the
> > > > > > same code for webdav & proxying. Could you file a jira for
this?
> > > > > >
> > > > > > Thanks,
> > > > > > Deng
> > > > > >
> > > > > > On Wed, Jul 9, 2008 at 8:45 PM, nicolas de loof <
> > nicolas@apache.org>
> > > > > wrote:
> > > > > >
> > > > > >> Hy,
> > > > > >>
> > > > > >> I get strange behaviour wen using repository group :
> > > > > >>
> > > > > >> From a fresh maven installation (empty local repo), with
> settings
> > > set
> > > > to
> > > > > >> mirror central to my archiva repository group URL, the eclipse
> 2.5
> > > > > plugin
> > > > > >> can't find the required org.eclipse.core:resources:[3.1.0,4.0.0)
> > > > > >>
> > > > > >> The maven-metadata.xml returned by the group URL is emty.
> > requesting
> > > > > >> metadatas from individual managed repos in the group are
fine.
> Is
> > > this
> > > > a
> > > > > >> known limitation ?
> > > > > >>
> > > > > >> Nico.
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>

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