2nd option may be simplier but not really nice, let's consider this use case
:
A user has an issue with a maven plugin. As a nice guy, he creates an issue,
attach a patch, but to get quick fix he deploys a snapshot to its corporate
repo.
To get it using a group repository ("public" proxying public repos +
"corporate"), we need to merge the metadatas from both repositories, so that
the custom snapshot will get listed in metadatas + all available version on
public snapshot repositories.
>From my understanding, this will require some "*list available files*" logic
+ "*merge metadatas*" in ArchivaDavResource.createResource(), and not just
"return resource;"
I've commited the "*list available files*" part that was trivial.
I'm not used with Dav (jackRabit) API and metadata file format, so any help
for the "*merge metadatas*" would be welcome (TODO at line 263). This would
require to create an "in memory" virtual resource for the merged metadata.
Nico.
2008/7/10 Maria Odea Ching <[EMAIL PROTECTED]>:
> Oh ok, sorry I thought it was a blank file returned. I haven't tried
> replicating it yet, was just looking through the codes.
> I guess either of the 2 options would work.. I'm still finishing up some
> things in the search, I'll see what I can do for 872 later tonight.
> Unless of course you want to work on it? :)
>
> Thanks,
> Deng
>
> On Thu, Jul 10, 2008 at 5:13 PM, nicolas de loof <[EMAIL PROTECTED]>
> wrote:
>
> > 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.
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
