You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ola Berg <ol...@arkitema.se> on 2002/08/12 00:16:26 UTC
The exegesis
>Have fun
No, it is not for fun. This is not fun at all, seeing really good and useful ideas getting voted down again and again and again.
When Stephen C proposed the ideas of what now is [pattern] (not the best name in the world but...), he was often turned down, because it to some people resembled a complete component framework.
After much debate, patterns project eventually came up, but it seems like the issue of what it may contain and deal with isn\'t sorted out yet.
There is this recurring pattern in the dialog:
-\"Hey, let\'s do feature X!\"
-\"No, ThingY already contains X!\"
-\"Yes, but this can exist in its own right, without having to depend on ThingY!\"
-\"So, you are being politically against ThingY?\"
I don\'t understand this fear for some common useful mechanisms, that can be used outside of the framework. Yes, that holds true for the life cycle methods too, they can be used outside of any current framework. They are simply generic things that need to be done on objects. Of course, used together within a certain framework can be a booster, but it is far from needed.
Judging from your reaction, I am not sure whether you didn\'t get what I meant, and so got offended for the wrong reason, or if you actually got it, even if it wasn\'t intended to be offensive.
Because: having common interfaces that _can_ be used in a life cycle management, is _not_ attempting to put Avalon in Commons. The thought is not very far sighted and looks like monopolistic fear.
It seems to me that rather than blaming some [pattern] people to be politically against Avalon, Avalon people who votes down slightly overlapping functionality from [pattern] should examine their own political standpoints visavi [pattern]. Esp since the votes aren\'t technically motivated, just a \"this shouldn\'t go in Commons\" \"This has Avalon already\" etc.
I mean, it is not that anyone would like to _force_ other projects to adopt to Patterns. And do the \"Commons is a place for packages that could be common for many jakarta projects\" mean that the packages in commons _have to_ be common for the jakarta projects? And the jakarta projects only?
In my company, we use Commons stuff for its own sake. We have stuff that we would like to contribute and adopt to Commons standards, as we think it fits with the charter. However, some of these things can be used in for instance life cycle management, and will thus be rejected, as stated by some of you.
(Resetable is an example, an interface that defines the method reset(). Useful in object pools and for object recycling, is well-suited in any configuration mechanism, but <em>is</em> useful elsewhere too).
I agree with anyone now thinking that my sarcastic remark on the Lords of Avalon was uneccessary. I guess that you write such things when you have banged your head against the wall too many times. For that I beg for forgiveness. I hope Stephen C can explain the ideas better than I can.
And I really do like Avalon (I am a Cocooner). Outfactoring the useful mechanisms (from both Avalon and elsewhere) that aren\'t interdependent on each other just seems so natural, _even_ if they should overlap existing functionality a bit. A mechanism that is useful for package A and B (whether they are in jakarta or not) should reside in package C. That is purely technical reason and common sense. Why don\'t let it happen? Why oppose it?
And if Commons isn\'t the place for it, then where is the place, so I can go there instead?
/O
(Sorry for creating so much fuzz, I guess this is considered noise. I\'ll be quiet from now on, working silently on Patterns and IO, sending stuff to Hen and Stephen C directly)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The exegesis
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ola Berg wrote:
...
> Because: having common interfaces that _can_ be used in a
> life cycle management, is _not_ attempting to
> put Avalon in Commons.
avalon-framework is the collection of such interfaces.
To use them:
import org.apache.avalon.framework.xxx.*;
Period.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The exegesis
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Hen has summed things up well here. A lot of the heated parts of all the
debate has been about misconceptions.
Stephen
----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>; "Ola
Berg" <ol...@arkitema.se>
Sent: Sunday, August 11, 2002 11:35 PM
Subject: Re: The exegesis
>
> I think some parts of this are unjustified Ola. Afaik, the only Avalon
> person here is Nicola, and his recent email is the first negative
> contribution he's made since joining I mean. Negative in terms of a -1
> rather than it being a bad contribution.
>
> It's not so much a thing to blame on Avalon people as it is a mentality of
> the Commons people. Commons and Avalon are coming out of a period of being
> [violently?, loudly] at odds with each other and in effect, one of the
> settlements was that Avalon was this big framework but it would use
> Commons for its internal common bits, and that the Commons developers
> didn't want to be putting together a framework style system, though this
> was more of a Commons belief than something Avalon cared about. Avalon
> have made far more steps to settlement than Commons at the moment.
>
> So the resistance [patterns] is feeling is not that of Avalon trying to
> say 'we alone should have that' but more that of Commons saying 'but we
> don't want frameworks'. Where Avalon should be able to come in is in terms
> of their experience in building a framework system, conventions and useful
> bits they can offer. Also that it may be that the [patterns] components
> would be better suited to live in avalon, up for debate.
>
> So the process is a lot about convincing Commons projects that they would
> benefit from adhering to a common set of patterns. Then whether other
> Jakarta projects would etc etc.
>
> There are definitely a lot of philosophical/technical/real-worldical
> discussions abotu [patterns] and holding it back from developing. How
> Stephen has managed to stop himself from turning up at OSCON with an uzi I
> don't know :) I suspect Prozac.
>
> The other half of things is that of avoiding redundancy. That's mainly
> where Avalon comes in. Patterns can reinvent the wheel if it wants to,
> it's commonly stated that there's no rule saying you can't have two
> similar projects in Jakarta, but usually it's helpful to everyone to have
> those two projects share notes from time to time. Or merge. etc etc.
>
> Just a view from someone who likes the idea of patterns but thinks it's a
> difficult path to walk.
>
> Hen
>
> On Mon, 12 Aug 2002, Ola Berg wrote:
>
> > >Have fun
> >
> > No, it is not for fun. This is not fun at all, seeing really good and
> > useful ideas getting voted down again and again and again.
> >
> > When Stephen C proposed the ideas of what now is [pattern] (not the
> > best name in the world but...), he was often turned down, because it
> > to some people resembled a complete component framework.
> >
> > After much debate, patterns project eventually came up, but it seems
> > like the issue of what it may contain and deal with isn\'t sorted out
> > yet.
> >
> > There is this recurring pattern in the dialog:
> >
> > -\"Hey, let\'s do feature X!\" -\"No, ThingY already contains X!\"
> > -\"Yes, but this can exist in its own right, without having to depend
> > on ThingY!\" -\"So, you are being politically against ThingY?\"
> >
> > I don\'t understand this fear for some common useful mechanisms, that
> > can be used outside of the framework. Yes, that holds true for the
> > life cycle methods too, they can be used outside of any current
> > framework. They are simply generic things that need to be done on
> > objects. Of course, used together within a certain framework can be a
> > booster, but it is far from needed. Judging from your reaction, I am
> > not sure whether you didn\'t get what I meant, and so got offended for
> > the wrong reason, or if you actually got it, even if it wasn\'t
> > intended to be offensive.
> >
> > Because: having common interfaces that _can_ be used in a life cycle
> > management, is _not_ attempting to put Avalon in Commons. The thought
> > is not very far sighted and looks like monopolistic fear.
> >
> > It seems to me that rather than blaming some [pattern] people to be
> > politically against Avalon, Avalon people who votes down slightly
> > overlapping functionality from [pattern] should examine their own
> > political standpoints visavi [pattern]. Esp since the votes aren\'t
> > technically motivated, just a \"this shouldn\'t go in Commons\" \"This
> > has Avalon already\" etc.
> >
> > I mean, it is not that anyone would like to _force_ other projects to
> > adopt to Patterns. And do the \"Commons is a place for packages that
> > could be common for many jakarta projects\" mean that the packages in
> > commons _have to_ be common for the jakarta projects? And the jakarta
> > projects only?
> >
> > In my company, we use Commons stuff for its own sake. We have stuff
> > that we would like to contribute and adopt to Commons standards, as we
> > think it fits with the charter. However, some of these things can be
> > used in for instance life cycle management, and will thus be rejected,
> > as stated by some of you.
> >
> > (Resetable is an example, an interface that defines the method
> > reset(). Useful in object pools and for object recycling, is
> > well-suited in any configuration mechanism, but <em>is</em> useful
> > elsewhere too).
> >
> > I agree with anyone now thinking that my sarcastic remark on the Lords
> > of Avalon was uneccessary. I guess that you write such things when you
> > have banged your head against the wall too many times. For that I beg
> > for forgiveness. I hope Stephen C can explain the ideas better than I
> > can.
> >
> > And I really do like Avalon (I am a Cocooner). Outfactoring the useful
> > mechanisms (from both Avalon and elsewhere) that aren\'t
> > interdependent on each other just seems so natural, _even_ if they
> > should overlap existing functionality a bit. A mechanism that is
> > useful for package A and B (whether they are in jakarta or not) should
> > reside in package C. That is purely technical reason and common sense.
> > Why don\'t let it happen? Why oppose it?
> >
> > And if Commons isn\'t the place for it, then where is the place, so I
> > can go there instead?
> >
> > /O (Sorry for creating so much fuzz, I guess this is considered noise.
> > I\'ll be quiet from now on, working silently on Patterns and IO,
> > sending stuff to Hen and Stephen C directly)
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: The exegesis
Posted by Berin Loritsch <bl...@apache.org>.
> From: Henri Yandell [mailto:bayard@generationjava.com]
>
> I think some parts of this are unjustified Ola. Afaik, the
> only Avalon person here is Nicola, and his recent email is
> the first negative contribution he's made since joining I
> mean. Negative in terms of a -1 rather than it being a bad
> contribution.
And me! don't forget me! Seriously though, Nicola has taken
the banner and really sought to merge the common bits--collections,
lang, etc.
> It's not so much a thing to blame on Avalon people as it is a
> mentality of the Commons people. Commons and Avalon are
> coming out of a period of being [violently?, loudly] at odds
> with each other and in effect, one of the settlements was
> that Avalon was this big framework but it would use Commons
> for its internal common bits, and that the Commons developers
> didn't want to be putting together a framework style system,
> though this was more of a Commons belief than something
> Avalon cared about. Avalon have made far more steps to
> settlement than Commons at the moment.
There is a bit of idealogical blockades to work through. Remember
that tearing down the Berlin wall did not happen overnight. It
took a long time for east and west Germany to heal their wounds.
By acting too soon, we can make the relationships between the
two projects of Avalon and Commons worse rather than better.
> So the resistance [patterns] is feeling is not that of Avalon
> trying to say 'we alone should have that' but more that of
> Commons saying 'but we don't want frameworks'. Where Avalon
> should be able to come in is in terms of their experience in
> building a framework system, conventions and useful bits they
> can offer. Also that it may be that the [patterns] components
> would be better suited to live in avalon, up for debate.
>
> So the process is a lot about convincing Commons projects
> that they would benefit from adhering to a common set of
> patterns. Then whether other Jakarta projects would etc etc.
Exactly. Commons is for common utilities, etc. Avalon is a framework.
Commons charter states no framework. Avalon can live with this--even
though there are some things in Commons that are suspiciously like
frameworks. We realize that it can't be helped.
I don't know much about the charter of patterns, but I will say
that lifecycle methods don't really sound like they belong to
a Commons project. BTW, we don't consider Resettable/Recyclable
(the Avalon equiv.) to be a real lifecycle interface.
> There are definitely a lot of philosophical/technical/real-worldical
> discussions abotu [patterns] and holding it back from
> developing. How Stephen has managed to stop himself from
> turning up at OSCON with an uzi I don't know :) I suspect Prozac.
:)
> The other half of things is that of avoiding redundancy.
> That's mainly where Avalon comes in. Patterns can reinvent
> the wheel if it wants to, it's commonly stated that there's
> no rule saying you can't have two similar projects in
> Jakarta, but usually it's helpful to everyone to have those
> two projects share notes from time to time. Or merge. etc etc.
There is nothing wrong with raising awareness. If a solution is
already covered, then we will state it. BTW, as soon as Commons
makes a new Collections release, we will be deprecating our version
and linking to the commons site. I'm sure that Commons developers
would see it in their heart to point people to Avalon for lifecycle
methods to...
> Just a view from someone who likes the idea of patterns but
> thinks it's a difficult path to walk.
I have no idea what Patterns is supposed to accomplish, but I agree
it is a difficult path to walk. The fact that Patterns is a bunch
of interfaces, implies the fact that it is a framework to build
implementations of the patterns with. That kind of violates the
Commons charter.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The exegesis
Posted by Henri Yandell <ba...@generationjava.com>.
I think some parts of this are unjustified Ola. Afaik, the only Avalon
person here is Nicola, and his recent email is the first negative
contribution he's made since joining I mean. Negative in terms of a -1
rather than it being a bad contribution.
It's not so much a thing to blame on Avalon people as it is a mentality of
the Commons people. Commons and Avalon are coming out of a period of being
[violently?, loudly] at odds with each other and in effect, one of the
settlements was that Avalon was this big framework but it would use
Commons for its internal common bits, and that the Commons developers
didn't want to be putting together a framework style system, though this
was more of a Commons belief than something Avalon cared about. Avalon
have made far more steps to settlement than Commons at the moment.
So the resistance [patterns] is feeling is not that of Avalon trying to
say 'we alone should have that' but more that of Commons saying 'but we
don't want frameworks'. Where Avalon should be able to come in is in terms
of their experience in building a framework system, conventions and useful
bits they can offer. Also that it may be that the [patterns] components
would be better suited to live in avalon, up for debate.
So the process is a lot about convincing Commons projects that they would
benefit from adhering to a common set of patterns. Then whether other
Jakarta projects would etc etc.
There are definitely a lot of philosophical/technical/real-worldical
discussions abotu [patterns] and holding it back from developing. How
Stephen has managed to stop himself from turning up at OSCON with an uzi I
don't know :) I suspect Prozac.
The other half of things is that of avoiding redundancy. That's mainly
where Avalon comes in. Patterns can reinvent the wheel if it wants to,
it's commonly stated that there's no rule saying you can't have two
similar projects in Jakarta, but usually it's helpful to everyone to have
those two projects share notes from time to time. Or merge. etc etc.
Just a view from someone who likes the idea of patterns but thinks it's a
difficult path to walk.
Hen
On Mon, 12 Aug 2002, Ola Berg wrote:
> >Have fun
>
> No, it is not for fun. This is not fun at all, seeing really good and
> useful ideas getting voted down again and again and again.
>
> When Stephen C proposed the ideas of what now is [pattern] (not the
> best name in the world but...), he was often turned down, because it
> to some people resembled a complete component framework.
>
> After much debate, patterns project eventually came up, but it seems
> like the issue of what it may contain and deal with isn\'t sorted out
> yet.
>
> There is this recurring pattern in the dialog:
>
> -\"Hey, let\'s do feature X!\" -\"No, ThingY already contains X!\"
> -\"Yes, but this can exist in its own right, without having to depend
> on ThingY!\" -\"So, you are being politically against ThingY?\"
>
> I don\'t understand this fear for some common useful mechanisms, that
> can be used outside of the framework. Yes, that holds true for the
> life cycle methods too, they can be used outside of any current
> framework. They are simply generic things that need to be done on
> objects. Of course, used together within a certain framework can be a
> booster, but it is far from needed. Judging from your reaction, I am
> not sure whether you didn\'t get what I meant, and so got offended for
> the wrong reason, or if you actually got it, even if it wasn\'t
> intended to be offensive.
>
> Because: having common interfaces that _can_ be used in a life cycle
> management, is _not_ attempting to put Avalon in Commons. The thought
> is not very far sighted and looks like monopolistic fear.
>
> It seems to me that rather than blaming some [pattern] people to be
> politically against Avalon, Avalon people who votes down slightly
> overlapping functionality from [pattern] should examine their own
> political standpoints visavi [pattern]. Esp since the votes aren\'t
> technically motivated, just a \"this shouldn\'t go in Commons\" \"This
> has Avalon already\" etc.
>
> I mean, it is not that anyone would like to _force_ other projects to
> adopt to Patterns. And do the \"Commons is a place for packages that
> could be common for many jakarta projects\" mean that the packages in
> commons _have to_ be common for the jakarta projects? And the jakarta
> projects only?
>
> In my company, we use Commons stuff for its own sake. We have stuff
> that we would like to contribute and adopt to Commons standards, as we
> think it fits with the charter. However, some of these things can be
> used in for instance life cycle management, and will thus be rejected,
> as stated by some of you.
>
> (Resetable is an example, an interface that defines the method
> reset(). Useful in object pools and for object recycling, is
> well-suited in any configuration mechanism, but <em>is</em> useful
> elsewhere too).
>
> I agree with anyone now thinking that my sarcastic remark on the Lords
> of Avalon was uneccessary. I guess that you write such things when you
> have banged your head against the wall too many times. For that I beg
> for forgiveness. I hope Stephen C can explain the ideas better than I
> can.
>
> And I really do like Avalon (I am a Cocooner). Outfactoring the useful
> mechanisms (from both Avalon and elsewhere) that aren\'t
> interdependent on each other just seems so natural, _even_ if they
> should overlap existing functionality a bit. A mechanism that is
> useful for package A and B (whether they are in jakarta or not) should
> reside in package C. That is purely technical reason and common sense.
> Why don\'t let it happen? Why oppose it?
>
> And if Commons isn\'t the place for it, then where is the place, so I
> can go there instead?
>
> /O (Sorry for creating so much fuzz, I guess this is considered noise.
> I\'ll be quiet from now on, working silently on Patterns and IO,
> sending stuff to Hen and Stephen C directly)
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The exegesis
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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.
Stephen
BTW: Ask yourself why [pattern] can have Resetable, but not Initializable??
There's no difference.
From: "Nicola Ken Barozzi" <ni...@apache.org>
> Stephen Colebourne wrote:
> > From: "Geir Magnusson Jr." <ge...@adeptra.com>
> >>On 8/11/02 6:26 PM, "Vincent Massol" <vm...@octo.com> 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
Avalon
> >>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
means
> > a particular set of interfaces that mean VERY precisely defined things
in a
> > contract that works ACROSS interfaces. When I talk about putting
lifecycle
> > type interfaces in [pattern] I mean interfaces that are INDEPENDENT of
one
> > 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
standalone
> > 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
extra
> > methods, but to add the cross-interface lifecycle contract that is at
the
> > 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.
>
> USE THEM! THEY ARE IN AVALON! >:-//
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The exegesis
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen Colebourne wrote:
> From: "Geir Magnusson Jr." <ge...@adeptra.com>
>
>>On 8/11/02 6:26 PM, "Vincent Massol" <vm...@octo.com> 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 Avalon
>>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 means
> a particular set of interfaces that mean VERY precisely defined things in a
> contract that works ACROSS interfaces. When I talk about putting lifecycle
> type interfaces in [pattern] I mean interfaces that are INDEPENDENT of one
> 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 standalone
> 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 extra
> methods, but to add the cross-interface lifecycle contract that is at the
> 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.
USE THEM! THEY ARE IN AVALON! >:-//
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The exegesis
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 8/11/02 7:06 PM, "Stephen Colebourne" <sc...@btopenworld.com>
wrote:
> From: "Geir Magnusson Jr." <ge...@adeptra.com>
>> On 8/11/02 6:26 PM, "Vincent Massol" <vm...@octo.com> 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 Avalon
>> 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
Not hard to understand. :)
> - Many commons people instantly -1 the moment 'lifecycle' is mentioned
I'm pretty much against a commons-framework, yes. Not sure I have the same
feelings about a lifecycle package, except if that implies "Thou must follow
this in commons". Otherwise, it's just a component in commons.
> - I have said that lifecycle type interfaces COULD go in [pattern]
>
> There is a degree of confusion however. Lifecycle to an Avalon person means
> a particular set of interfaces that mean VERY precisely defined things in a
> contract that works ACROSS interfaces. When I talk about putting lifecycle
> type interfaces in [pattern] I mean interfaces that are INDEPENDENT of one
> another, not part of a framework.
Ok.
> Is there really something scary about saying that if a class can be
> initialised then the method name should be initialize()?? As a standalone
> interface?
No, as long as you don't say that I should use it (and I am not suggesting
that is the case.)
>
> What if the lifecycle type interfaces were in [pattern] ?? The Avalon
> interfaces still exist - they extend the Commons version not to add extra
> methods, but to add the cross-interface lifecycle contract that is at the
> heart of Avalon.
Don't these already exist in Avalon as interfaces anyway, and the
cross-interface contract is just that, an understanding? I don't know how
you might mechanically enforce something deeper in Java.
> Re-read that last paragraph. Then read it again.
>
> If you understood it then everyone should be happy.
> - Lifecycle, as a framework, is in Avalon.
> - Lifecycle pattern interfaces are in [pattern].
I have trouble understanding the technical difference, as a lifecycle
interface package could exist in avalon, independent of the 'social'
contract of the framework practiced by Avalon.
I was just wondering what the huff was about. Thanks for the explanation of
your POV.
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The exegesis
Posted by Juozas Baliuka <ba...@mwm.lt>.
Hi,
<snip>
> You are proposing to move all the interfaces--or duplicate existing
> interfaces into Pattern.
>
> Why not have Pattern *use* the *existing* interfaces in Avalon?
> Oh yeah, I forgot--it's that political thing.
>
I do not think it is some political thing, It is because Avalon is not very
trivial to learn and use,
most of us are too lazy to study some framework and prefer to invent a new
one,
but I think the same will happen with a new framework, people will reinvent
it :)
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: The exegesis
Posted by Berin Loritsch <bl...@apache.org>.
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
>
> From: "Geir Magnusson Jr." <ge...@adeptra.com>
> > On 8/11/02 6:26 PM, "Vincent Massol" <vm...@octo.com> 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
> > Avalon 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
> - 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 means a particular set of interfaces that mean
> VERY precisely defined things in a contract that works ACROSS
> interfaces. When I talk about putting lifecycle type
> interfaces in [pattern] I mean interfaces that are
> INDEPENDENT of one another, not part of a framework.
Danger Will Robinson! Danger!
Seriously, this is where you can learn from the experience of the
Avaloners. It is quite common for component developers to take
advantage of the lifecyle sequence to set up their component to
be in a working state. If you change the sequence of calling the
lifecycle interfaces, it breaks the component.
Avalon *used* to have the interfaces unrealated to each other, with
the exception that Initializable would always be called last.
Experience taught us that we needed to guarantee a specific order
of calling the interfaces. By making them completely independent
of one another you end up increasing the time it takes to understand
how your stuff works as opposed to just using.
Avalon only has a steep learning curve because it is a jump from
OOP to COP. Component Oriented Programming (COP) builds on OO
principles, but provides much stricter guidelines and has a Container
to instantiate and manage the components in a system. Avalon is
not the only COP system out there. Servlets and EJBs are also
examples of COP based systems. Each Servlet is a component, as well
as each EJB.
> Is there really something scary about saying that if a class
> can be initialised then the method name should be
> initialize()?? As a standalone interface?
Hey we have that! Why not just use it? Why spend time and energy
relearning all the things we had to figure out?
> What if the lifecycle type interfaces were in [pattern] ??
> The Avalon interfaces still exist - they extend the Commons
> version not to add extra methods, but to add the
> cross-interface lifecycle contract that is at the heart of Avalon.
>
> Re-read that last paragraph. Then read it again.
Avalon Framework is a collection of interfaces. We have a logger
abstraction (no auto discovery of loggin implementation--that is
the responsibility of the container), we have configuration,
component lookup, Initializable, Disposable, Startable, Suspendable,
and more. However, these interfaces *ARE* Avalon Framework.
Anything more is in documentation, or in the containers we have in
Excalibur and Phoenix.
By placing the lifecycle interfaces in Pattern, you are effectively
moving Avalon Framework--or duplicating it in Pattern. What is
dangerous is not their existence, but the lack of consistency in how
they are applied. You will find that you *need* to specify a common
ordering so that you can properly build the tools to manage your
components.
>
> If you understood it then everyone should be happy.
> - Lifecycle, as a framework, is in Avalon.
> - Lifecycle pattern interfaces are in [pattern].
You are proposing to move all the interfaces--or duplicate existing
interfaces into Pattern.
Why not have Pattern *use* the *existing* interfaces in Avalon?
Oh yeah, I forgot--it's that political thing.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The exegesis
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Geir Magnusson Jr." <ge...@adeptra.com>
> On 8/11/02 6:26 PM, "Vincent Massol" <vm...@octo.com> 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 Avalon
> 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
- 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 means
a particular set of interfaces that mean VERY precisely defined things in a
contract that works ACROSS interfaces. When I talk about putting lifecycle
type interfaces in [pattern] I mean interfaces that are INDEPENDENT of one
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 standalone
interface?
What if the lifecycle type interfaces were in [pattern] ?? The Avalon
interfaces still exist - they extend the Commons version not to add extra
methods, but to add the cross-interface lifecycle contract that is at the
heart of Avalon.
Re-read that last paragraph. Then read it again.
If you understood it then everyone should be happy.
- Lifecycle, as a framework, is in Avalon.
- Lifecycle pattern interfaces are in [pattern].
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: The exegesis
Posted by Berin Loritsch <bl...@apache.org>.
> From: Geir Magnusson Jr. [mailto:geirm@adeptra.com]
>
> On 8/11/02 6:26 PM, "Vincent Massol" <vm...@octo.com> 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 Avalon Framework be in commons? Do the avalon people
> want it in commons? Why don't they want it in Avalon?
We want it in Avalon--its just that some people want it in commons.
So why not start using Avalon?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Framework in commons ? (was RE: The exegesis)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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).
yup.
> 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
grumbling.
> 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
classes+implementations.
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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon Framework in commons ? (was RE: The exegesis)
Posted by Berin Loritsch <bl...@apache.org>.
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon Framework in commons ? (was RE: The exegesis)
Posted by Vincent Massol <vm...@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.
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
interface
- put the component with its Avalon skin and make it a dependency on
avalon-framework.
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.
Thanks
-Vincent
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: 12 August 2002 16:13
> To: 'Jakarta Commons Developers List'
> Subject: RE: Avalon Framework in commons ? (was RE: The exegesis)
>
> > 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>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon Framework in commons ? (was RE: The exegesis)
Posted by Berin Loritsch <bl...@apache.org>.
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Avalon Framework in commons ? (was RE: The exegesis)
Posted by Vincent Massol <vm...@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).
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.
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'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>
Cheers,
-Vincent
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@adeptra.com]
> Sent: 11 August 2002 23:44
> To: Jakarta Commons Developers List
> Subject: Re: The exegesis
>
> On 8/11/02 6:26 PM, "Vincent Massol" <vm...@octo.com> 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
Avalon
> Framework be in commons? Do the avalon people want it in commons?
Why
> don't they want it in Avalon?
>
>
> --
> Geir Magnusson Jr.
> Research & Development, Adeptra Inc.
> geirm@adeptra.com
> +1-203-247-1713
>
>
>
> --
> To unsubscribe, e-mail: <mailto:commons-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The exegesis
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 8/11/02 6:26 PM, "Vincent Massol" <vm...@octo.com> 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 Avalon
Framework be in commons? Do the avalon people want it in commons? Why
don't they want it in Avalon?
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: The exegesis
Posted by Vincent Massol <vm...@octo.com>.
I haven't been following the discussion, but I agree with you : Avalon
Framework should be in Commons
-Vincent
> -----Original Message-----
> From: ola.berg@arkitema.se [mailto:ola.berg@arkitema.se]
> Sent: 11 August 2002 23:16
> To: commons-dev@jakarta.apache.org
> Subject: The exegesis
>
> >Have fun
>
> No, it is not for fun. This is not fun at all, seeing really good and
> useful ideas getting voted down again and again and again.
>
> When Stephen C proposed the ideas of what now is [pattern] (not the
best
> name in the world but...), he was often turned down, because it to
some
> people resembled a complete component framework.
>
> After much debate, patterns project eventually came up, but it seems
like
> the issue of what it may contain and deal with isn\'t sorted out yet.
>
> There is this recurring pattern in the dialog:
>
> -\"Hey, let\'s do feature X!\"
> -\"No, ThingY already contains X!\"
> -\"Yes, but this can exist in its own right, without having to depend
on
> ThingY!\"
> -\"So, you are being politically against ThingY?\"
>
> I don\'t understand this fear for some common useful mechanisms, that
can
> be used outside of the framework. Yes, that holds true for the life
cycle
> methods too, they can be used outside of any current framework. They
are
> simply generic things that need to be done on objects. Of course, used
> together within a certain framework can be a booster, but it is far
from
> needed.
> Judging from your reaction, I am not sure whether you didn\'t get what
I
> meant, and so got offended for the wrong reason, or if you actually
got
> it, even if it wasn\'t intended to be offensive.
>
> Because: having common interfaces that _can_ be used in a life cycle
> management, is _not_ attempting to put Avalon in Commons. The thought
is
> not very far sighted and looks like monopolistic fear.
>
> It seems to me that rather than blaming some [pattern] people to be
> politically against Avalon, Avalon people who votes down slightly
> overlapping functionality from [pattern] should examine their own
> political standpoints visavi [pattern]. Esp since the votes aren\'t
> technically motivated, just a \"this shouldn\'t go in Commons\" \"This
has
> Avalon already\" etc.
>
> I mean, it is not that anyone would like to _force_ other projects to
> adopt to Patterns. And do the \"Commons is a place for packages that
could
> be common for many jakarta projects\" mean that the packages in
commons
> _have to_ be common for the jakarta projects? And the jakarta projects
> only?
>
> In my company, we use Commons stuff for its own sake. We have stuff
that
> we would like to contribute and adopt to Commons standards, as we
think it
> fits with the charter. However, some of these things can be used in
for
> instance life cycle management, and will thus be rejected, as stated
by
> some of you.
>
> (Resetable is an example, an interface that defines the method
reset().
> Useful in object pools and for object recycling, is well-suited in any
> configuration mechanism, but <em>is</em> useful elsewhere too).
>
> I agree with anyone now thinking that my sarcastic remark on the Lords
of
> Avalon was uneccessary. I guess that you write such things when you
have
> banged your head against the wall too many times. For that I beg for
> forgiveness. I hope Stephen C can explain the ideas better than I can.
>
> And I really do like Avalon (I am a Cocooner). Outfactoring the useful
> mechanisms (from both Avalon and elsewhere) that aren\'t
interdependent on
> each other just seems so natural, _even_ if they should overlap
existing
> functionality a bit. A mechanism that is useful for package A and B
> (whether they are in jakarta or not) should reside in package C. That
is
> purely technical reason and common sense. Why don\'t let it happen?
Why
> oppose it?
>
> And if Commons isn\'t the place for it, then where is the place, so I
can
> go there instead?
>
> /O
> (Sorry for creating so much fuzz, I guess this is considered noise.
I\'ll
> be quiet from now on, working silently on Patterns and IO, sending
stuff
> to Hen and Stephen C directly)
>
> --
> To unsubscribe, e-mail: <mailto:commons-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>