commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: The exegesis
Date Sun, 11 Aug 2002 22:52:31 GMT
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" <bayard@generationjava.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>; "Ola
Berg" <ola.berg@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:
<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>
>


--
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