On Thu, Jan 30, 2003 at 03:22:50AM +0100, Stephen McConnell wrote: > Vadim Gritsenko wrote: ... > >I kind of understand this part about bringing non-avalon components > >into Avalon, and also I don't completely agree with this (without > >further thinking), my question was a bit about different thing. Your > >argumentation can justify redefenition of "Avalon Component" term to > >include all Objects. But why deprecate all existing Avalon Components > >(now you have to go and fix'em all and fix all your containers which > >expect Component - Cocoon's case) by deprecating Component interface? > >I mean, you can extend definition of component and include all this > >non-Avalon thingies out there (if you see that it's possible and adds > >value), but this by itself does not require deprecation of Component > >interface. Which means, there is something more to it... > > > Lock-in on Component and the related classes (ComponentManger, > ComponentException, ComponetSelector, etc. is basically a bad thing. > The service package provides a parallel solution that does not lock you > into Avalon. All it requires in that someone takes care of the > transition. ComponentXxxxxx gets relpleaces by ServiceXxxxx - and > Composable by Servicable. I did the transition on my own stuff (which is > bigger than Cocoon and it took me half a day - James took two hours). > Cocoon needs someone to do the job of transition. > > As concerns justification - my background is strongly aligned with > international standards - and guess what - they don't declare standard > components via org.apache.avalon.framework.component.Component. This is > nothing more that an artificial limitation on your developers. If you > want to introduce a JDBC driver as a component - you cannot because it > does not implement Component - there is something wrong in that equation > - Avalon is a framework - it is not the global definition of Component. > Avalon 4.1.3 is an open solution - all you need to do is choose between > liberty and proprietary. > > Over to you!
But this is arguing for the carrot when someone complains about the stick. Clearly there are advantages of Serviceable, but they seem totally independent of whether Component has a @deprecated tag or not. When I boot my Win95 box, I don't get a popup warning me that it's obsolete. IMO: - cocoon-dev should call for volunteers to Serviceable'ize the codebase. If none come forward before beta, use a recompiled Framework without the @deprecated - avalon-dev should consider if the stick (@deprecated) is really necessary, if the carrot (eliminating the Component interface) is so compelling. --Jeff > Cheers, Steve. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
