commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <>
Subject RE: Avalon Framework in commons ? (was RE: The exegesis)
Date Mon, 12 Aug 2002 16:13:29 GMT
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.

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

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

- put the component with its Avalon skin and make it a dependency on

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.


> -----Original Message-----
> From: Berin Loritsch []
> Sent: 12 August 2002 16:13
> To: 'Jakarta Commons Developers List'
> Subject: RE: Avalon Framework in commons ? (was RE: The exegesis)
> > From: Vincent Massol []
> >
> > 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-
> For additional commands, e-mail: <mailto:commons-dev-

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

View raw message