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 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.

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). 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



Stephen J. McConnell

Reply via email to