it's important that our user community understands that we consider ComponentManager "suboptimal" and "replaced by something better". That's exactly what a deprecation tag is ment to indicate, so I think it's good practice to use them.
OTOH, I am okay with removing the @deprecation tags if it means a lot to the cocoon people/user community; the message they are conveying has already come across: IIUC cocoon3 will be using ServiceManager as much as possible :D
So yeah, weighing those two things, +1 on your suggestion.
I would just like to point out that I in general consider it not a good idea to base much judgement or decision on deprecation tags. Look at how it is handled in the jdk. Everything that was in 1.1 is in 1.4, and I doubt anything will be removed in 1.5. There's some kind of education issue towards users in there perhaps as well...hmm.
cheers,
- Leo
Leo Sutic wrote:
I'd just like to see what you in Avalon-dev have to say about this:
<snip/>
It seems like the @deprecation of ComponentManager etc. is annoying
some people to a fairly large extent.
I was thinking... Could we remove the @deprecated tags from the classes in question and just leave it with a note in the JavaDocs saying that the service.* package is much much better and that you should use it
instead unless you have a reason not to?
As I understand it, every container must support ComponentManager,
Composable, etc. anyway... At least until Avalon 5.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
