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 20:38:42 GMT

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 dev@maven (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 
>>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

View raw message