From: http://www.jadetower.org/muses/archives/000019.html
> So this is my first proposal (and perhaps the most radical): Break up > the Avalon Framework. Let's take our own medicine and seperate > concerns. Seperate lifecycles into an avalon-lifecycle framework. > Create a generic way to support user defined lifecycles and perhaps > include a standard set of lifecycles used by and fully supported by > all official Avalon containers. > > Seperate out the service package into a true IoC framework which > focuses on dependency resolution. Provide support for all sorts of > IoC types. But focus on just this one issue.
+1, this is very much aligned with my own vision of what A5
should be about> So, is Avalon about the Framework or is it about a Container? > (Yes, there are other options, but I'm trying to build an > arguement here. :) ). I know that there are some Avaloners who > feel strongly about unifying all efforts behind the standard of > one true Container. In that case, (here comes another radical > idea), perhaps what we need to consider is putting Merlin on > the roadmap for becoming it's own top level project. Or perhaps > we need a place for just framework development. But I am > concerned that as soon as we tie to two too closely together, > the power of the framework will be lost in the implementation of > the container.
Avalon isn't about the Framework or a Container. Instead, from our charter, Avalon is about community concerned with the development and publication of open-source software dealing with component and service management.
From this assertion there are a few things that are worth pushing onto the table - the most central point is that we are a product focused community. Within this context the principal of "one product" introduced a set of very health social dynamics. It forces community cohesion. If you don't like something you have to do something about it within the context of a single product framework - and the procedures at Apache facilitate collaborative and radically approaches to this. The key and socially binding principal is that these procedures ensure that there is only ever one product.
In the document you described the Holly Grail as "a single container which is truly generic". The solution is as much about community as it is about technology. We have some issues to deal with here at Avalon with respect to multiple product branches - and resolution will not be easy to achieve - but finding the Holly Grail has never been a walk in the park.
Cheers, Steve.
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
