commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ola Berg <>
Subject The exegesis
Date Sun, 11 Aug 2002 22:16:26 GMT
>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

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

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

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?

(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:   <>
For additional commands, e-mail: <>

View raw message