avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <aok...@bellsouth.net>
Subject Fwd: Re: [part due] What is an ArtifactDatabase?
Date Fri, 07 Nov 2003 03:33:44 GMT

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

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 platforms.
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 repository@apache.org list is going.  In the words of that great American
hero, G.I. Joe, "that's half the battle."


> >>From: Niclas Hedhman <niclas@hedhman.org>
> >>Date: 2003/11/06 Thu PM 09:29:42 EST
> >>To: "Avalon Developers List" <dev@avalon.apache.org>
> >>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

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message