Very sound advice and keen observations ... you're right!  Time will tell and 
we need to start making some baby steps in the right direction for now.  I 
think involvement with the Maven people in defining what a repository is for 
one single Apache repository is most important first.  

Extention of this repository with artifact attributes to enable the application 
based characterization of artifacts is the next step.  The POM can be stored 
there and so can other application specific deployment attributes if the Maven 
people want to go there.  The nice thing is if done right we can query for 
these artifacts based on their attributes to build a very powerful base to all 
The ideas to come out of Maven and Merlin regarding a repository and its use 
are very powerful.  Maven invented it and Merlin showed us how to use it to 
manage an environment.  Both are very powerful innovations.

>From what I can see even Loom at jContainer is following that same route and 
>this proves the fact that a connection exists.  The biggest danger today is 
>the potential for community fragmentation.  Apache does not need two copies of 
>the same thing.

The technical details will come together but let's do it right as one 
community.  I think this is where the [EMAIL PROTECTED] list is going.  In the 
words of that great American hero, G.I. Joe, "that's half the battle."


> >>From: Niclas Hedhman <[EMAIL PROTECTED]>
> >>Date: 2003/11/06 Thu PM 09:29:42 EST
> >>To: "Avalon Developers List" <>
> >>Subject: Re: Repository, Bootstrapping and Embedding
> >>
> >>On Friday 07 November 2003 05:12, Stephen McConnell wrote:
> >>    
> >>
> >>>>I believe apps are artifacts that can be kept in the repo with its
> >>>>dependencies.  There are no limitations.  Why treat application artifacts
> >>>>any differently?  
> >>>>        
> >>>>
> >>I basically agree. And, yes, more "try and see" is probably required.
> >>
> >>    
> >>
> >>>I'm mainly thinking here about the stuff that Niclas Hedhman has been
> >>>talking about.  Personally I think its a different viewpoint on the
> >>>component model and I'm still figuring out what that viewpoint
> >>>encompasses and what its relationship is to existing content and service.
> >>>      
> >>>
> >>Basically,
> >>almost ever single application needs something beyond "code" and 
> >>"resources" ( 
> >>resource as in ClassLoader.getResourceAsStream() ).
> >>
> >>At _application_ level, we have bunches of stuff that is pretty much 
> >>common, 
> >>for instance;
> >>
> >>1. Help system
> >>2. Installation instructions.
> >>3. Temporary storage.
> >>4. Configuration files.
> >>
> >>but no matter what list I produce, someone will say "and ...", so for the 
> >>moment, we just accept "stuff".
> >>
> >>Looking at the capability of installers, it is evident that there is a 
> >>great 
> >>deal of requirement surrounding "stuff", may it be due to platform, 
> >>language, 
> >>installation choices, or a dozen other conditions and combinations between 
> >>conditions. I think you get the picture.
> >>
> >>NOW, bringing this to our scenario;
> >>Often components are aware of many "conditions" in the deployment scenario, 
> >>and should (this is something new from head) expose not only the "stuff" 
> >>(artifacts) but the conditions for each such artifact.
> >>How this can be done? No clue at the moment, but FSM and/or scripting comes 
> >>to 
> >>mind.
> >>
> >>At the far end, one could imagine that a set of conditions are given, and 
> >>the 
> >>application self-assemble the "stuff" into a running application. Why not?
> >>What would that do to server (or client for that matter) management?
> >>
> >>We have a long way ahead, but even the longest journeys start with small 
> >>steps.
> >>
> >>
> >>Niclas

Reply via email to