Vadim Gritsenko wrote:
Jeff Turner wrote:Yes, those deprecation warnings are annoying and misleading, because Component is deprecated for Avalon, not Cocoon. Perhaps Cocoon should have a special avalon-framework-nodepr-4.1.3.jar , without the @deprecated?
My thinking, exactly... I mean, we are going to support Cocoon 2 for some time, without changing basic interfaces like Generator, Action, etc. And lots of @deprecation in there won't help in raising user's confidentiality.
Avalon gurus out there - should we fork framework? ...
Answering not to "guru", but to "fork" ;-)
Yes, all these deprecation warnings are annoying, and furthermore destroy the usefulness of deprecating some classes in Cocoon since we remove all deprecation warnings.
But instead of forking, what about a tool that automatically removes the deprecation flag on thoses Avalon classes that aren't considered deprecated in Cocoon ?
A small BCEL-based tool could easily do the trick, and would be used before committing a new version of Avalon jars in Cocoon's CVS.
Thoughts ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
