archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maria Odea Ching" <>
Subject Re: [discuss] repository metadata
Date Fri, 08 Aug 2008 06:31:23 GMT
On Thu, Aug 7, 2008 at 9:12 PM, Brett Porter <> wrote:

> Any thoughts?
> On 28/07/2008, at 2:31 PM, Brett Porter wrote:
>  Hi,
>> For some time (probably close to 2 years!) I've been thinking about a
>> different way of storing metadata in the repository due to limitations in
>> Maven's metadata (both the maven-metadata.xml files and POM files) -
>> primarily a lack of extensibility (and thus the tie to Maven itself). In
>> addition, I'd like to avoid the requirement to have a database for Archiva
>> to work (and rather have it as a useful addition for easy searchability).
>> I think it'd be interesting to start being able to attach arbitrary
>> metadata to artifacts. For example:
>> * Maven metadata as it does now
>> * OSGi information extracted from the JAR
>> * Ivy metadata so we could bridge those repos and vice-versa
>> * references continuous build results
>> * references to historical coverage, test, etc results
>> * allowing users to add their own metadata types and attach them
>> About a year ago at DevZuz we had a lot of success with a prototype of a
>> metadata repository (based on the now defunct Eclipse Kepler project) that
>> could read in Maven repositories but also other repository types, and then
>> store that in Kepler format and push it to other sources (we had a JPA
>> store, for example). I'm not proposing to use any of that, but the idea
>> worked out well.
>> So, I've been thinking about making some changes to Archiva along these
>> lines.
>> I would see this as becoming the "state" Archiva knows about a repository
>> (and it should be entirely self-contained). So the lucene indices, database,
>> and others are purely alternate storage mechanisms of the metadata for
>> various applications of it.
>> Each element is timestamped making scanning operations simpler. When you
>> run a particular consumer it can just check if the metadata for it is there
>> already, and add or update it as needed (so a "full scan" would be
>> reasonably efficient still).
>> While the metadata can be stored inside the repository, it should be
>> possible (and maybe preferable?) to store it completely separately. This
>> also makes it possible for one metadata repository to represent multiple
>> source artifact repositories (possibly on a different server - you could run
>> an Archiva scan on that repository and push metadata updates over JMS/REST
>> to the database/lucene-backed webapp).
>> I think it would be valuable to use a format that is easily bridged to web
>> services to avoid too much rework..
Sounds good to me :) I liked the idea of the Kepler project before and I
think it would fit nicely with Archiva.
This seems like a lot of work though, maybe we could schedule this after

>> That's just some of my thoughts for now. What do others think?
>> James, how would this fit with your new repository API?
>> Cheers,
>> Brett
>> --
>> Brett Porter

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