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. This idea
has been thoroughly discussed in Maven-land.

> * 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. The Loom and Pico folks are
also doing similiar things so we have a wealth of information and
experience to gain from those folks too. Michal has been working on
Wagon and has had many discussions with Peter Donald who has some
fantastic ideas vis-a-vis repositories and application production and
application runtime.

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

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

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.

Jason van Zyl

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  -- Jacques Ellul, The Technological Society

Reply via email to