-----Original Message----- From: Berin Loritsch [mailto:[EMAIL PROTECTED]
To that end, we need to focus on the AMTAGS proposal and the Context clarifications. Currently, there is a similarity in some of the component definitions between Phoenix and Fortress, with Merlin being divergent in these areas.
Perhaps to avoid any misunderstanding, how exactly is Merlin divergent?
The meta-info and meta-data descriptors are different for all three containers. This includes assembly, lifestyle identification, and configuration. Deployment structure (jar vs sar) is different between all three containers. Support for lifecycle extensions, nested containers, context extensions and values are different in all containers.
Fortress and Phoenix share a subset of meta-info descriptors, as well as some common context entries.
For now, our concerns rely mostly with
1) Meta information (includes info/data) 2) Context entries 3) Anything that is in the "avalon" namespace.
The assembly is something that needs to be addressed, but I would be comfortable with addressing it at a later time. Fortress and Merlin do share some semantics with configuration--I would like to see that much be the same between all containers. Fortress and Merlin do support lifecycle extensions, though they are declared differently.
It is not a call to trash Merlin and vindicate others. It is a call to unify the Avalon namespace. Anything that is beyond the scope of the Avalon namespace needs a different namespace. Component writers need to know what they can expect in all containers. If they use lifecycle extensions, how do they declare them (in AMTAGS, not in XML which is an implementation concern)?
We already have a certain number of issues on the table, and releasing Merlin will exacerbate those issues if we have not addressed them before the release.
My _goal_ is to have a core set of functionality that component writers can work with, and allow that core functionality to be extended in ways that make new containers (or more specifically container extensions) the way of the future.
I wanted to raise the issues for a number of reasons. The chief of which is that no sandboxed development can emerge out of the sandbox until there is proper developer support for it. If it will have the Apache Avalon name stamped on it, the Apache Avalon team must be behind it. I have no doubt that Stephen has done a wonderful job with Merlin. It has been flying under the radar for a long time, and we need to address it sooner than later. Esp. if Stephen is hinting about a near release. It can't be released without developer backing. I would prefer to get developer backing than tell him that Merlin cannot be released.
However the implications of a Merlin release means that we the Avalon developer community have to get our act together on certain issues. We do not have to come to a unified featureset, but we do have to come to a unified set of rules for how to extend the core featureset in predictable ways.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
