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 <[EMAIL PROTECTED]>: > 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 <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]>: > > > > > 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 <[EMAIL PROTECTED]> > > > 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 <[EMAIL PROTECTED]>: > > > > > > > > > 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 < > [EMAIL PROTECTED]> > > > > > 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 < > > [EMAIL PROTECTED]> > > > > > 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. > > > > > >> > > > > > > > > > > > > > > > > > > > > >
