Berin, >> framework.component2.ComponentManager >> framework.component2.Composable > > I think this is shoving us to too much change too soon. I propose the > following > solution: > > 1) Finish ContainerManager classes et. al. to prove how feasible it is > to make > Component and ThreadSafe marker interfaces unnecessary. > > 2) Have some time to learn from the implementation (what can we do > better?). > > 3) After our lessons learned phase, start considering An Avalon 5.0 > tree to start > cleaning out cruft and fixing things (like Configuration being an > interface but > Parameters being an implementation).
You can start that tree Berin but I cannot use it. EOB sits on Phoenix and that already has the existing framework jar in the classpath. I could not replace that beacue it would barf without a complete rework of phonix. In short I'll stick to my own framwork interfaces and not use those from a fledling framework 5.0 > If we feel confident that Avalon is ready for a reconstruct, we can > discuss this > at length. But before we consider an Avalon 5.0 release date, we need > to have > ContainerManager and friends moved out of scratchpad, the > excalibur.component > package deprecated, and the arrangement exist for a couple of releases. Timing timing, EOB needs the return type of Object. It is developing fast and building a small community. > By encouraging people to an alternative like the ContainerManager > approach, we > enable a smoother migration to Avalon 5.0--whatever form it may take. > > Paul, I like your enthusiasm, but we don't want to jerk our users > around, or > give them the impression that is what we are doing. > > For all these reasons, I would have a strong -1 to putting those > interfaces > in Framework at this time. > > Furthermore, there are other things we may want to explore, such as a > Query object > on the ComponentManager. These changes will undoubtedly force more > deprecations > and unhappy people. You leading me to belive this is a 6-9 month process. I'd hope that the abolition of Component as a marker interface could be seen as so easy to implement (and ripple through other codebases), that it could be done as an addendum to the curent release. Large refactor work scares me, as you'll be associatig a simple change with a huge change. My motives are purely selfish, I have a case for composable without insiting on Component now.. Sorry dude... - Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
