commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: [pool] PROPOSAL: add collecting of statistics to pool implementations
Date Fri, 26 Apr 2002 16:22:40 GMT

> > My definition of macro vs micro is probably best expressed as giving
> > someone a lego kit in a box versus giving someone lots of lego bricks. In
> > the former there is a defined way to build the system, though you can play
> > with it. In the latter it's entirely up to you.
>
> I think that is a good analogy.  Although you can still take legos from
> different kits and come up with new creations. :)  I used to do that all
> the time.  In some ways, I still do.

And to push the analogy to its bounds, by taking lego from different kits
you end up with quite an ugly product :) Plus you get all your pieces
muddled up.

I think that Excalibur/Commons needs to get a good solution in place
before the consumers get confused. It seems to be a frequent problem in
Jakarta-land. JSTL/Taglibs and JJAR/Maven also suffer from it.
The user sits there and can't discern an immediate difference between the
products. mod_webapp/mod_jk is another example.

The Jakarta virus? Duplication. I know sourceforge has this lots, but
you'd expect it there as you're not dealing with one entity. But Jakarta
is one entity to the external consumer, so the duplication problem is a
very poor selling point.

Only solution I can think of is for aggressive management so that when two
projects appear to be considered duplicate, the two projects must produce
a plan for how the duplication will be dealt with.

Like having a regulator who walks around the system checking that everyone
is still following the initial project plan.

That would work for JJAR/Maven. They started with very different aims and
it's happened that a sub-part of Maven and JJAR have the same
functionality.

For JSTL/Taglibs it wouldn't make sense as it was obvious from the outset
(probably) that they would clash. In this case I would assume that the
duplication plan would have to be known from the outset.

How does this sound? I guess the actual end result would be that
Avalon/Commons would somehow have to display a clear description of how
they relate. Ditto for JJAR/Maven.

Hen


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