> From: Paul Hammant [mailto:[EMAIL PROTECTED]] > > > +1 for Phoenix becoming a top level project. > > As well .... > > * Excalibur bits go to Commons or elsewhere, apart from the > bits used by one or other container, > which go with that container.
> * Merlin leaves Avalon CVS. Go to scratchpad, yes, but leave? > * Logkit goes to top level? Maybe... > Avalon becomes Avalon-Framework, which I've said over and > over again is the only level at which compataibility between > containers is guaranteed (and that we all agree on). > Some > containers have xml component lacing, some another type of > xml lacing, yet others have _no_ meta data. Still, there *is* a meta model for components. For example, even if the container doesn't provide any support for it, some components *do* have dependencies. I see no harm in having classes in framework that can be used to hold that minimal set of data. The danger comes when we introduce elements that do not correspond to an intrinsic property of components. For example, remotable, etc... Or worse, couple the metamodel to some kind of lifecycle processing code, making it more than just a holder of information and thus binding it to a container implementation. Peter Donald's latest info proposal looked like it could be just that, but it didn't seem to survive the travel from private email exchanges to the general list. (I also see no problem with them having an XML representation, as in "if you're going to use an xml representation of this in your container, we recommend you use this one...". For example, even though Configuration objects are build from XML in most cases, and the DefaultConfigurationBuilder builds from XML, there's nothing in the Configuration contract that says that it *must* be XML based.) /LS -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
