commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: Avalon Framework in commons ? (was RE: The exegesis)
Date Mon, 12 Aug 2002 16:21:51 GMT
> From: Vincent Massol [mailto:vmassol@octo.com] 
> 
> I agree with you Berin. I was probably a bit provocative ... :-)
> 
> I myself have no problem with Avalon being in Avalon because 
> I understand what Avalon is and its benefits (I like to think so!). 
> 
> However, Avalon still suffers from adoption. Not because 
> people don't like it but I think mostly because they are 
> ignorant of what it is and what it brings to them. It needs 
> to be democratized/evangelized.

True, although there are several projects that use Avalon, as well as
a book in the works that uses it (for generic component oriented
programming).


> In my view Jakarta Commons could be a good play ground for 
> that (of course not forcing anyone to use Avalon). 
> 
> Avalon suffers from its name which represents several 
> different things: a set of interface, differents component 
> manager/containers, some useful components and some 
> applications based on these components.
> 
> I believe lots if not all Excalibur components should be 
> brought to the commons (I think this has started already 
> under's Nicolas's help).

All the generic subsubprojects like CLI/Event/Collections/etc.,
are in the process of being merged or superceded by the commons
counter parts.

> 
> We have 2 choices for moving the Excalibur components in commons:
> 
> - separate the excalibur component moved to commons from 
> Avalon Framework and make a wrapper in Excalibur land to wrap 
> it with an Avalon interface

-1.  The component is a component.  I don't like having too many
layers of wrappers.  It just slows things down.


> - put the component with its Avalon skin and make it a 
> dependency on avalon-framework.

I would prefer this.

> 
> I would prefer the second option because it brings me 
> additional value but for that to happen, we would need an 
> easy to use and transparent component manager that would work 
> in all environments ... hum ... Maybe that's where the 
> problem is ... ? :-)
> 
> Just day dreaming ... I'll shut up now.

We are working on this problem now.  We have two different
containers that are very powerful, yet easy to use.  We are
currently merging the concepts into one approach--which will
allow us to have a good, easy to use, container.

It's coming--but not as quickly as we all might like to see.


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message