avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject RE: Officially Deprecate ComponentManager and friends?
Date Sat, 20 Jul 2002 13:34:44 GMT
> > If I go through and make sure that all the remaining 
> > excalibur components are 
> > Serviceable rather than Composable can I deprecate 
> > ComponentManager and 
> > friends? All the containers now support Serviceable 
> > components so that should 
> > not be a problem. Any objections?
> 
> -1 based on the few reasons you gave:
> 
> What does a @deprecated tag mean?

If you look at java.* and javax.* it does not mean we loose it in the
next major release java.util.XXXStream is still around.

>  + If the deprecation means "this interface will not exist
>    in Avalon 4.2" then I'm -1 on it - too fast. I think
>    we have to support it until A5.

me too. Deprecation means marking it as deprecated; when to remove the
interface is not part of the proposal.

>  + If the deprecation means "this interface will not exist 
>    in A5" then you should deprecate Serviceable too, as
>    ServiceLocator / ComponentLocator is the A5 name/interface.

I think we should not deprecate Serviceable just yet. There may not be
A5 for a long time, whereas 4.2, 4.3 etc is likely. In those I'd like to
see CM deprecated in favor of SM.

> Plus:
> 
>  + Any project using A4 and Composable will get massive 
>    amounts of deprecation warnings for really no good
>    reason. Imagine compiling a system that has been
>    build with CM/Composable. You get a gazillion deprecation
>    warnings and it is just not fun anymore.

yup. But you can disable deprecation warnings.

> Basically, just stuff a "<b>We strongly recommend that you
> use Serviceable / ServiceManager instead</b>" in the Javadocs.
> Don't use @deprecated to indicate what we recommend against
> using - just use it for things that will actually *disappear*
> in the next release/version (4.2?).

My bet is that the next version will be 4.2, so marking it as deprecated
from now on in CVS means not deprecating in 4.1.XX but in 4.2.

The way I see it, @deprecated is *exactly* to point out what we
recommend not to use.

Anyway, whether we formally deprecate using @deprecated or just text in
the javadoc doesn't matter to me. The "formally" part is what is
important.

cheers,

- Leo



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


Mime
View raw message