commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Avalon Framework in commons ? (was RE: The exegesis)
Date Mon, 12 Aug 2002 08:05:42 GMT

Vincent Massol wrote:
> In my vision, all jakarta components would benefit from using lifecycle
> interfaces. 

I agree.

> I would also be very much in favor of having a very very
> lightweight component manager available for all these components.

I agree.

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

> I believe the Avalon project provides several pieces of this puzzle: the
> Avalon Framework itself and maybe one of its component manager (aka
> container).


> However, this would mean that any user downloading any framework from
> commons would need to also have Avalon Framework + lightweight component
> manager. In the same spirit as almost anyone getting a commons framework
> needs commons-logging. For that to work, I believe it would be much
> easier for the Avalon Framework to be in commons. Same with that
> lightweight component manager.

We have our logging because of stupid political/ego stuff.
Recently some of us have proposed commons logging instead, but got some 

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

I repeat, I don't see the need to have the Avalon-framework in Commons 
rather than in Avalon.
Is the place where the code is infecting?
Does it make the code less good?
Why is it that a package named commons-* is nicer than one named 
avalon-* ?!?

> 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
> - Commons gets its lifecycle framework (Avalon framework)
> - 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]
> Let's see the flames ...
> <putting my flamesuit on>

If you want to have avalon framework and commons in a single
repository you will need a new project and a new charter.

You see, Avalon started as a Common Framework.
And now it *is* the common framework.

What has happened is that Avalon has become a framework+utility 

This causes confusion because Commons was created that does only the 
"utility classes" part.

/Personally/, I would be ok for the following conceptual and maybe 
phisical separation, please comment on this, and please try not to flame:

The next packages rely on the previous:

- Avalon Framework
- new Jakarata Commons (Jakarta Commons + Avalon Excalibur)
- Avalon Services (Avalon Cornerstone and Turbine Services)
- Avalon Servers (Phoenix, Merlin/Fortress)
- Avalon Apps

This is what is more technically sensible for people that want to use 
common interfaces in Commons.

This can already be done now, if only the Commons committers would 
permit making some commons stuff depend on Avalon framework :-/

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message