commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: The exegesis
Date Mon, 12 Aug 2002 20:05:37 GMT
Nicola, (Berin),
A little while back you suggested that I might help clarify the boundaries
between Avalon and Commons. Well I have, but maybe only in my own mind...

I think there is pretty much agreement on the following:
- Avalon defines component lifecycle interfaces
- Commons should not define component lifecycle interfaces

The key word is 'component'.

Javadoc for 'Initializable' from Avalon:
"Initialialize the component. Initialization includes allocating any
resources required throughout the components lifecycle."

Javadoc for Avalon framework package:
"The Framework part of Avalon contains interfaces and contracts surrounding
those interfaces, along with default implementations of some of those
interfaces. Among other things, these interfaces impose a COP development
model. "

These two pieces of javadoc, IMO, explain why Avalon is good, but also why
lots of people don't use it. Avalon is about a COP development model. Its
interfaces help define that. But there is also documentation and other
best-practice that goes beyond actual Java code. That's great. But none of
that has anything to do with commons. And is why commons will never depend
on Avalon.

What I would like to do with [pattern] is define common method signatures.
These can be used by _any_ object, not just by components. They do not
specify an order. They do not require a container. They are, in essence,
meaningless (as opposed to Avalon, where each interface has great meaning).
This is the great leap of faith for an Avaloner like yourself. Can you
accept that a method signature, such as initialize(), can standalone?

> Niclola wrote:
> There is NO TECHNICAL NEED of having interfaces like these.

Actually thats half the point. No, I'm not mad! And maybe its just a
different programming style to yours. My argument is that Initializable in
[pattern] has no baggage, no implications, no significance, nothing. Its
just a suggestion for a method name. On the other hand, Initializable in
Avalon requires COP, and thus associated issues.

Initializable in Avalon is thus a specialism of the generic Initializable in
[pattern]. But a specialism that adds COP semantic meaning. It gives you no
technical benefits (well virtually none - there would probably be a Command
adaptor in [pattern]).

(BTW, I'm a realist. I don't actually expect Avalon to suddenly go out and
change its interfaces to extend [pattern]. Yet.)

My idea of [pattern], outlined above, is radical. And so is the relationship
to Avalon.


BTW: Ask yourself why [pattern] can have Resetable, but not Initializable??
There's no difference.

From: "Nicola Ken Barozzi" <>
> Stephen Colebourne wrote:
> > From: "Geir Magnusson Jr." <>
> >>On 8/11/02 6:26 PM, "Vincent Massol" <> wrote:
> >>
> >>
> >>>I haven't been following the discussion, but I agree with you : Avalon
> >>>Framework should be in Commons
> >>
> >>I haven't followed either, but just explain the above - why should
> >>Framework be in commons?  Do the avalon people want it in commons?  Why
> >>don't they want it in Avalon?
> >
> >
> > The views seem to be (generalising):
> > - Avalon people want lifecycle in Avalon
> Avalon folks *HAVE* lifecycle in Avalon.
> Before Commons came along, Avalon *was* the Java Apache Commons.
> > - Many commons people instantly -1 the moment 'lifecycle' is mentioned
> > - I have said that lifecycle type interfaces COULD go in [pattern]
> >
> > There is a degree of confusion however. Lifecycle to an Avalon person
> > a particular set of interfaces that mean VERY precisely defined things
in a
> > contract that works ACROSS interfaces. When I talk about putting
> > type interfaces in [pattern] I mean interfaces that are INDEPENDENT of
> > another, not part of a framework.
> >
> > Is there really something scary about saying that if a class can be
> > initialised then the method name should be initialize()?? As a
> > interface?
> Useless and confusing.
> There is NO TECHNICAL NEED of having interfaces like these.
> > What if the lifecycle type interfaces were in [pattern] ??  The Avalon
> > interfaces still exist - they extend the Commons version not to add
> > methods, but to add the cross-interface lifecycle contract that is at
> > heart of Avalon.
> >
> > Re-read that last paragraph. Then read it again.
> You read it, and try to understand.
> Why the heck should we extend the Commons version?!?!
> Tell me a TECHNICAL need. A REAL one though.
> > If you understood it then everyone should be happy.
> > - Lifecycle, as a framework, is in Avalon.
> > - Lifecycle pattern interfaces are in [pattern].
> Gee, if you need them, go ahead and do them, but you will keep getting
> -1s from me and probably the rest of the world.
> You need those interfaces.
> --
> Nicola Ken Barozzi         
>              - verba volant, scripta manent -
>     (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message