cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Re-precating (?) classes (was: RE: What is a Parser?)
Date Sat, 01 Feb 2003 18:47:59 GMT
Nicola Ken Barozzi wrote:
> 
> Peter Donald wrote:
> 
>> On Thu, 30 Jan 2003 08:05, Leo Sutic wrote:
>>
>>> I'd just like to see what you in Avalon-dev have to say about this:
>>
>>
>>
>> Update Cocoon to latest Avalon code and remove Component from the 
>> Cocoon codebase (A 30 min job?) and the deprecation warnings will go 
>> away.

Right.

> We have to provide full backward compatibility in 2.x series; all 
> Components and Composables must be honored; core interfaces like 
> Generator, Transformer, Serializer all extend Component and this can not 
> be changed.


Keep in mind the following:

#1 The Composables *will* be honored.
#2 The Component interface does *not* add any functionality.  It can
    also be added _dynamically_.
#3 We can safely remove the Component interface (the source for most
    deprecation warnings).
#4 We can move to using the Serviceable components instead of the
    Composables so that all _Cocoon_ code can properly mark deprecation
    on components itself without any deprecations comming from the Avalon
    code.

All this can be done with the current CVS version of ECM and Fortress.
Currently it requires JRE 1.3 or higher.  If JRE 1.3 is unnacceptable,
then *please* let us know, and we will make ECM 1.2 compatible by using
the CGLIB library with a drop in replacement for JRE 1.3 dynamic
proxies.

> 
> This will make sense for 3.0.

It even makes sense in the real short term.  As soon as ECM is released,
you will be able to use the *same* code, and not worry about the
Component/Composable interfaces.  THey *will* be supported.

> 
> As Vadim pointed outm, OTOH, timing for such changes is really not good 
> - we just have 3 books published recently.

And another one that should be done around April (for Avalon and
component oriented programming).

> 
>  From an engineering POV removing @deprecated sucks. But it's also true 
> that from a user perspective, having deprecation warnings on core Cocoon 
> components, ant that is all of them simce we use Avalon heavily, sucks 
> even more.

The user won't have to worry about them.

> 
> I'm mildly in favor of removing the @deprecation tag and putting it in 
> the docs, but I'm not sure either.
> 

I'm not.  We just need an ECM released RSN.  THe Avalon team is putting
together releases for everything.  We just need to know if it is
acceptable with the Cocoon folks if JRE 1.3 is the minimum or not.



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message