commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re: The exegesis
Date Sun, 11 Aug 2002 22:35:04 GMT

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.


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

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message