commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <>
Subject RE: The exegesis
Date Sun, 11 Aug 2002 22:26:07 GMT
I haven't been following the discussion, but I agree with you : Avalon
Framework should be in Commons


> -----Original Message-----
> From: []
> Sent: 11 August 2002 23:16
> To:
> 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
> name in the world but...), he was often turned down, because it to
> people resembled a complete component framework.
> After much debate, patterns project eventually came up, but it seems
> 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
> ThingY!\"
> -\"So, you are being politically against ThingY?\"
> I don\'t understand this fear for some common useful mechanisms, that
> be used outside of the framework. Yes, that holds true for the life
> methods too, they can be used outside of any current framework. They
> 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
> needed.
> Judging from your reaction, I am not sure whether you didn\'t get what
> meant, and so got offended for the wrong reason, or if you actually
> 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
> 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
> 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
> be common for many jakarta projects\" mean that the packages in
> _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
> 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
> instance life cycle management, and will thus be rejected, as stated
> some of you.
> (Resetable is an example, an interface that defines the method
> 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
> Avalon was uneccessary. I guess that you write such things when you
> 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
> 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
> purely technical reason and common sense. Why don\'t let it happen?
> oppose it?
> And if Commons isn\'t the place for it, then where is the place, so I
> go there instead?
> /O
> (Sorry for creating so much fuzz, I guess this is considered noise.
> be quiet from now on, working silently on Patterns and IO, sending
> to Hen and Stephen C directly)
> --
> 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