avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@citi-us.com>
Subject RE: On Multiple Containers
Date Thu, 21 Nov 2002 20:03:38 GMT
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Peter Royal wrote:
> > 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.
> 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.
> Allowing people to work on their own pet container created 
> many one-man 
> shows. *THIS* has to stop.

Hmm.  Phoenix represents a container that is not embeddable, and
the containers in development in Excalibur have the goal of becoming
embeddable (within a larger context).

For that reason, Phoenix may have to become its own Top Level Project.
It is not, nor really should be the reference implementation.  Its
role is nevertheless very important, and the codebase should not
be thrown away.

> IMHO (and I don't get to vote on the Avalon PMC) The Avalon 
> *NOT* allow more than *ONE* sub-project implementing an 
> avalon container.

We don't agree, and I've already stated reasons why.

> Avalon in fact is:
>   - a framework
>   - a container
>   - a collection of components

That is currently what it is.

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

It is important then that they allow components that are tied to
Avalon.  Jakarta Commons did not allow that.  Yet another reason
why Excalibur was created.  The problem is that Excalibur grew
to more than just a repository for components.

> Then Avalon is left managing:
>   - the framework
>   - the framework reference implementation container
> That's it. We don't need anything more than this.


What would go in this reference implementation container?  What
would you do with the work that has *already* been performed on
different container architectures?  How would you address the
issues involved in finetuning the process of defining the core
reference implementation of a container?

Hopefully you are not suggesting that we throw away all that

ECM has both the complaint and support of several developers.
Fortress has the support of several developers--and provides
a migration path from ECM.
Merlin has one major contributor, and a couple of patches
applied here and there by other developers.
Phoenix is too large and special purposed to become the
reference implementation.

We need to move from ECM, and the choice is really Fortress
or Merlin.  Both have some really cool things about them,
as well as some things that detract from them.

At this point, we need to unify the *standards*.  Once we
have standards, we can piece together the reference
implementation.  In the meantime, Fortress and Merlin have
earned a right to exist--the question is where.

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

We are working toward that--but we have a ways to go.

> There is only one crime around Apache: not caring about the 
> value of the 
> communities.

There is one thing about Apache--the communities are stronger
here on average than in other places (like sourceforge).

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

We still need to address the other issues I listed above.

> Let's try to stop fragmentation.

Other than Phoenix, we have two real prospects.  They can both
live peacably for the very near future.  In fact, the Fortress
and Merlin containers have been working on cross-polinating
ideas and concepts.  The eventual understanding is that there
will be one standard for the contracts between the container
and the component.  That also means that Fortress will be
able to host Merlin containers and vice versa.

Throwing away hard work and community development for a clean
slate isn't very good either.

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message