Stephen McConnell wrote: ...
This is not what I intend.
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.
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.
Look at Cocoon, we cannot build a Cocoon without dozens of deprecated classes. This means that deprecation has been totally inefective.
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.
I understand what your aiming at - just not convinced about the approach ;-)Yeah, that's why it's a proposal. ;-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
