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 15:13:16 GMT
> From: Vincent Massol [mailto:vmassol@octo.com] 
> 
> In my vision, all jakarta components would benefit from using 
> lifecycle interfaces. I would also be very much in favor of 
> having a very very lightweight component manager available 
> for all these components.
> 
> If we had this, I believe both the quality of our code (IOC 
> pattern really rules and makes the software really 
> configurable for all needs from the outside which is probably 
> a very good things for jakarta code) and ease the 
> understanding of our code for anyone looking at it: clear, 
> well-known interfaces, etc.
> 
> I believe the Avalon project provides several pieces of this 
> puzzle: the Avalon Framework itself and maybe one of its 
> component manager (aka container).

Ok, now we are really thinking backwards here.  Keep in mind that
Avalon predates Commons by a fair amount.  I do not advocate having
Commons swallow an EXISTING project at the root level of Jakarta.

If you really want to use it--its there to use.  However keep in
mind that you are going to have to teach users what IoC is, SOC is,
etc.  IOW, you have to duplicate Avalon's documentation.

I am very -100000000 on moving an existing root level project to
inside of Commons.


> What would still be outside (as is now) are the more complex 
> containers like Phonenix and the others. I would also 
> envision that once Avalon framework becomes a Commons 
> component, then all Excalibur components can find their place 
> in commons as separate components, in much the same way as 
> existing commons components.
> 
> So my vision is Avalon Framework everywhere :-) but for that 
> to happen I believe it has to be in commons as it would be 
> common to every component. 

So is our vision--however, what's wrong with using it where it
is, as opposed to making an artificially forced code move?
Does the fact that it has the name "Avalon" in the package name
offend you?

> 
> I'll sure get a lof of flames from both camps but think about 
> it, as I think it is in the best interest of everyone :
> 
> - Avalon is used throughout the whole jakarta and by everyone 
> using any component of commons (probably without them even 
> knowing), thus spreading its knowledge

That is a misconception.  Practice will play out that you will
not see that happen.  It is exposed at a higher level than
Commons.  How is moving it within Commons going to make it more
"popular"?

> 
> - Commons gets its lifecycle framework (Avalon framework)

Commons can still use Avalon framework where it is now.


> - Users get real components, that implement best practices 
> that everyone agrees on (especially IOC - I hope you do agree 
> with IOC, right ? :-)) and they get better quality, more easy 
> to read and understand code.
> 
> [Yes, one of the very nice effect of IOC is that it makes 
> unit testing them a breeze]


And Avalon has a testing harness that instantiates the components
and any required supporting components into a container and lets
you exercise them.

However, again, what's wrong with using it where it is now?  What's
wrong with a commons project depending on Avalon framework?



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