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:[EMAIL PROTECTED]] > 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
