avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [PROPOSAL] Deprecation policy ( Re: [Proposal] LogKit Release Plan )
Date Sat, 01 Feb 2003 23:16:08 GMT

Nicola Ken Barozzi wrote:

> Stephen McConnell wrote:
> ...
>> Honestly - I think its a bad thing to do.  Deprecation is something 
>> that can be formally applied at a Java source file level and 
>> inforomally defined on other artificats (configs, etc).  I would 
>> prefer this sort of thing to be managed at the CVS level in 
>> conjuntion with appropriate build procedures.  If you tag something 
>> in CVS as a 1_X branch, then under that a 1_1 branch, and things get 
>> deprecated - when you do the 2_X branch - that's the point where the 
>> deprecated content dissapears.  By introducing a xxx/classic and 
>> xxx/compat your basically moving the notion of branching out of CVS 
>> and into the file structure. 
> This is not what I intend.
> In 1.0 I have a class.
> In 1.1 i deprecated it and move it in the src/deprecated dir.
> In 2.0 I remove the deprecated stuff.
> The benefits in 1.1 are that I can be *sure* that the core package 
> doesn't need the deprecated classes to compile, that the users 
> understand better that they are deprecated, and that users that want 
> to not use deprecated stuff can do so without having the deprecated 
> stuff in the classpath.

This works when you have a relatively clean seperation - e.g. building 
framework without the component package is a viable proposition. 
 However, if you look at the logkit scenario you have non-deprecated 
class that are referencing depricated classes.  Which means that 
deprecated classes need to be brought back into the standard java/src in 
order to build.  I.e. the strategy breaks because of the non-deprecated 
referencing depricated cases.

> Look at Cocoon, we cannot build a Cocoon without dozens of deprecated 
> classes. This means that deprecation has been totally inefective.

Actually I think there is a darker problem underlying all of this.  When 
we do "COP" we design with an ever present notionof service verus work 
interface.  When we think about changing things, I've seen several cases 
of changes that maintain the service interface but break the inheritance 
based usage. Based on the problesm I am seeing related to COP usage - 
I'm moving in favour of component classes being declared final, but 
backed by a non-final abstract class.  The reason is that making 
promises relative to inhertence is a totally different subject relative 
to maintaining a service contract.  

>> Clearly things in the file structure tend to be easier to manage - 
>> but at the same time I think it has a bunch of hidden problems. Test 
>> cases in one example, but what about configurations, property files, 
>> etc.  At the end of the day I think that this comes down to better 
>> management of CVS tags and synchronizing builds against tagged content.
> Hmmm, probably you don't get the point, see above.
> The simplest thing is to do the following:
> 1) compile the source
> 2) compile the deprecated classes with (1) in classpath
> 3) use the two packages combined in all following steps
> In this way you get the separation benefits without additional problems.

Assuming there are not deprecated classes referenced in you main src tree.
(and that's a big assumption)

Cheers, Steve.

>>> Yeah, that's why it's a proposal. ;-)
>> I understand what your aiming at - just not convinced about the 
>> approach ;-)


Stephen J. McConnell

To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

View raw message