www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Scope/Phasing
Date Fri, 07 Nov 2003 16:48:58 GMT

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, 
and application.

The structural viewpoint deals with naming conventions (group, type, 
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 
  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 
  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 
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

View raw message