commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@octo.com>
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

-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:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message