Component deprecation warnings (Re: What is a Parser?)

[Jeff Turner <je...@apache.org>]

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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Serviceable, Was: Component deprecation warnings (Re: What is a Parser?)

[Vadim Gritsenko <va...@verizon.net>]

Jeff Turner wrote:
...

>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
>  
>

Given the fact that we have to provide full backward compatibility in 
2.x series, which means that all Components and Composables must be 
honored, what is the reason moving to Serviceable except to confuse 
people even more?

Please take into account that interfaces like Generator, Transformer, 
Serializer all extend Component and this can not be changed.

My thinking is that this makes sense for 3.0. Then you can change base 
Cocoon interfaces, remove Component everywhere, remove support for 
Composable, etc. OTOH, timing for such changes is really not good - we 
just have 3 books published recently. I think there are better issues to 
be resolved before spending energy on this.

Vadim


> - 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org