Peter Royal wrote:
Pete and I discussed a lot about this yesterday and I really *DO*NOT* see the need for more than one avalon container implemented under the avalon PMC.On Wednesday, November 20, 2002, at 06:03 AM, Berin Loritsch wrote:Multiple containers are not only helpful, but they are absolutely necessary.
We will never be able to converge on the most generic and useable container
specifications when there is only one to choose from. Using different
approaches that all work with the same components helps us to determine
important criteria such as:
I think a single container is a goal we should strive towards. Users don't want to have to pick a container due to separate but overlapping feature sets. We should strive towards a single container that is pluggable to the point of satisfying many needs. I think the current experimentations with multiple containers lets us push things into different directions to see what we may want from that ubercontainer.
Allowing people to work on their own pet container created many one-man shows. *THIS* has to stop.
IMHO (and I don't get to vote on the Avalon PMC) The Avalon PMC *SHOULD* *NOT* allow more than *ONE* sub-project implementing an avalon container.
Avalon in fact is:
- a framework
- a container
- a collection of components
Apache Commons or Jakarta Commons are much better places for shared components and services so we should make an effort to move everything that is potentially sharable there.
Then Avalon is left managing:
- the framework
- the framework reference implementation container
That's it. We don't need anything more than this.
Let's stop this idiotish fight between containers. If individuals on this list can't work together, they'll either learn or leave. It's life and it's human.
There is only one crime around Apache: not caring about the value of the communities.
The container showmen (yes, there are more than one!) on this list should take a step back and understand that the *real* reasons why Avalon can't converge on a single container.
Let's try to stop fragmentation.
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
