commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject RE: [pool] PROPOSAL: add collecting of statistics to pool implementations
Date Sat, 27 Apr 2002 18:51:39 GMT
Henri,


You even forgot to put Turbine in the equation. There is duplicated
code across the Commons, Avalon AND Turbine.

However, "aggressive management" is NOT a solution. Not even in the
"corporate world".


If you try to choose a winner between 2 or 3 groups you end up with a
war in your hands and many of the losers moving somewhere else since
they do not want to work with something they do not believe on.


Then, you also end up with ONLY the knowledge of the winners.

There is also the problem that it is often not clear which solution
is better for a given problem. Sometimes you need quite some time for
that to become clear.

And often there is more than an ideal tool - it just depends on the
style and believes of the person using the tool.


OTOH, if you help all the groups communicating with each other and
learning from each other:
 - A lot of cooperation, exchange of knowledge and other synergies
   will spontaneously form;
 - "Natural selection" will tend to exclude the worse bits overall;
 - Everybody will be happier.

Some Turbine guys are already contributing a lot to the commons and
some Avalon guys too.

I also do not care much about confused users, especially for
development tools. One always gets confused when choosing a tool
anyway, even when it is a commercial tool. Why should Open Source
tools be different.

And then, there are the different styles. Most Avalon users would
never use Turbine and most Turbine users would never use Avalon.


As usual, "aggressive management" would just kill the creativity
and productivity we now have, which I consider quite impressive.


Have fun,
Paulo Gaspar


> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com]
> Sent: Friday, April 26, 2002 6:23 PM
>
> ...
>
> 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