Jason van Zyl wrote:

On Fri, 2003-11-07 at 11:48, Stephen McConnell wrote:

Adam R. B. Jack wrote:

Three comments (probably all repetitions) :

1) Perl/Python have a package index/identification approaches. We might want
a similar concept, i.e. queriable metadata that associates keywords/concepts
with packages/groups/artefacts. These concepts could be language sensitive
(so either different, or extended). These concepts/approaches could be
argued as complimentary/orthogonal to repository, i.e. not in scope.

2) I am already overwhelmed by this information produced just around the
discussion of the URL (location) of files, and the differences in needs for
Java and/or others. We've not even started on the meat of the issues with
this venture. My gut tells me that having a repo effort, with per language
sub-efforts is the only way to achieve success & not a
one-size-doesn't-fit-all-kludge. [I could be wrong, but I point to 1 above
for this.]

3) Maybe we just phase things, and be happy with that. Maybe phase one is
the Maven-like/Avalon-like repository on an HTTP server w/ minimal metadata.
However hard we discuss the issues I doubt we'll get the "real world"
experience maintaining a repository (with mirrors, and such) unless we roll
up our sleeves and manage one on Apache hardware w/ partner mirrors. I think
prototyping and phasing are keys here.

I tend to agree.

Based on the experience gained in the Avalon repository work there are a
number of distinct viewpoints: structural, relational, organizational/legal, and application.

The structural viewpoint deals with naming conventions (group, type, artefact, version) and the associated access machinery - getting, putting, navigation.

* The relational viewpoint concerns information about artefacts such as
dependencies - and here we start see language specifics. For example a jar file with structural dependencies. This leads to the necessity to include a artefact descriptors. One example is the Maven POM - but its not good example at this level of abstract because its a descriptor of build and test time dependencies (amongst other things).

The POM is not an artifact descriptor at all. The work done by Michal is
more akin to what you speak of where types of artifacts themselves are
described and controlled by handlers associated with the type.

My impression is that this is specific to the Maven POM model - which is for all intensive purposes meta-data for the purpose of artifact generation. When you are looking at runtime service deployment model there are bunch of things that the POM does not address (which is to be expected as the POM is not addressing service management).

However, if we look at repository enabled applications in general, covering applications such as Maven with a focus on development process together with applications such as the avalon-repository with its focus on runtime service deployment, you draw from these common information model requirements and potential common services that map into a shared abstraction. It's that common abstraction which is a subject I'm interested in.

This idea has been thoroughly discussed in Maven-land.

Based on the [EMAIL PROTECTED] (which I've been following closely since Febraury) the discussions are properly grounded on the development process abstraction. I think we are talking about something more generic both in terms of meta information and services. However, if we dig down, there are clealy common facilities. In fact this (common facilities) is where a lot of value can be gained.

What this basically comes down to is probably something like:

         Maven                        Avalon
 (development process focus)   (service deployment focus)
           |                             |
           |                             |
                 Java Langauge Focus
                      Repository Aware Application Focus

* The organizational/legal viewpoint is partly reflected in the Maven POM
 model with information concerning the organization name, contributors and
 so forth.  One of the important aspects here is licensing.

* The application viewpoint is where a repository really shines. For example the Maven project uses a repository as the source of build-time artefacts. The Avalon team are using the repository as a source of artefacts for things like dynamic classloader hierarchy creation, automated bootstrapping of components, coordinated management of apis, spis and implementations. At this level what is largely missing in the underlying repository service is a flexible meta-model and an efficient protocol.

As far as building applications, I have been doing this for well over a
year with Plexus and its runtime builder.

Building or composing?

Michal has been working on Wagon

Do you know if Michal is subscribed to this list?

In order to address these limitations we are currently extending our existing
repository model to support bootstrapping of alternative back-end storage
strategies and protocols - with LDAP as the primary candidate (based on a
collaboration with the Apache Directory Project team).

Again, as I've mentioned before information as a decoration is certainly valuable. LDAP is certainly one possibility, object stores using something like OJB and Prevayler are also things I've personally experimented with.

But really I think the notion of a repository is really not that complex
and I will work this weekend in order to submit a proposal based on the
valuable experience I've gained from Maven usesr and some of the ideas
we've come up while developing Wagon (which will be showing up in a
repository near you asap).

Can you give me a URL to the Wagon iniative?

Cheers, Steve.

There is also
some initial work going on with respect to a repository plugin for eclipse
that is aiming at drag-and-drop component assembly relative to repository

One of the things that I think will be really important is simply getting
this up and running here at Apache in order to facilitate a better
understanding different repository aware applications and from that ..
a better understanding of the common requirements across different

That's definitely a good idea. Hopefully the existing Avalon Maven
repository may serve as a valuable example. Over the next week I will
finish a tool to extract artifacts from the standard archives produced
by the various projects here in order to facilitate the mirroring of
Apache artifacts to Ibiblio as requested by the board. So shortly there
will be fully populated maven-style repository and hopefully that too
may serve as a valuble example we can all work from.



Stephen J. McConnell

Reply via email to