commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [pool] PROPOSAL: add collecting of statistics to pool implementations
Date Fri, 26 Apr 2002 17:00:42 GMT
Henri Yandell wrote:
>>>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.

You have no imagination. ;P

Sometimes I came up with something better than any of the kits allowed.

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

In the last case, its easy: mod_webapp is replacing mod_jk.

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

I doubt you will ever get that through the voting process.  There are
too many developers in Jakarta land that oppose strong project

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

All that would happen is a bunch of "this project is better because XYZ"
and there would be little objective data to back up the claims.


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

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

View raw message