On Fri, 2003-11-07 at 15:38, Stephen McConnell wrote:
> 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.  

The counter example to that is how plugins currently work. It is seen as
a plugin type, prepared and installed. Very simple process, but
extrapolate and you have component deployment.

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

No, the POM doesn't at all address components, services or particular
component models. 

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

To me this discussion is focused on an artifact repository. Not that
component deployment isn't important (I'm doing it myself) but you can
build whatever information you require from the artifacts you put into
the repository that are made to work with your system. In your case

There is absolutely nothing stopping you, with the structure of the
current Maven repository, from keeping a directory of available
components for use with, say, Merlin or Plexus. I believe the discussion
of dynamic component deployment is beyond the scope of the discussion
here. I'm definitely interested but I don't think it's a notion that
should be baked into the notion of the repository. 

I currently keep a primitive list of components that can be used with
Plexus and users can select them. Anything that I've needed I have been
able to add to the repository simply as another artifact type. So in our
case it may be a component descriptor which you may want to process in
whatever way is necessary to make it work with your component model and
component deployment model.

What specific problems have you run into? I haven't run into any yet

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

Most definitely.

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

This should not be baked into the repository simply because there are so
many ways to define what the meta information is and you will never get
a consensus on what that should be and it simply isn't needed. Not for
the repository itself. 

For any use case you can provide I think I could suggest a way to
utilize what exists right now.

> 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

Service deploy, and Repository Aware applications are outside the scope
of the repository. You can build whatever information stores you want
and deploy them to the repository for use. I am ardently opposed to
baking any of these specific notions into the repository structure

> Building or composing?

Simply building, I compose using component descriptors of my own

> >Michal has been working on Wagon
> >
> Do you know if Michal is subscribed to this list?

Not sure if he is yet, but I've asked him to.

> Can you give me a URL to the Wagon iniative?

Not yet, but I will be able to soon. The Maven PMC members are
discussing the finer details now.

In summary I would say we keep the notions simple. I am convinced that
the discussion of the repository need not delve into topics of service
deployment or repository aware applications. This is entirely within the
domain of the implementors of these systems and I am one them so I speak
from some practical experience in the matter. Plexus and Merlin may both
have their own component deployment model and repository aware
applications and I have certainly thought of these things and I have yet
to be hindered with what currently exists. Additionally there is no way
you could ever standardize on these things given the existence of Pico,
Nano, Loom, Plexus, Carbon, Merlin, Spring, SOFA, Fractal just to name a
few of the existing containers and component models. There is simply no
chance you're going to get them all to converge and you don't have to.
Each implementation can do what they like.


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