However if you get the source it would be nice to show a rename intention or at least a tool tip that contains the methods/classes listed under @see tags. A javadoc tool tip could show the deprecation message instead of saying : method has been deprecated which is rather useless once you know what striked out methods are.
http://java.sun.com/products/jdk/1.1/docs/guide/misc/deprecation/deprecated. html Jacques "Guillaume Berche" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]... > Hi, > > When an external library changes, one needs to update its code to reflect > this change. While such changes (package/class/method renaming) occur > infrequently in public libraries, this is more often the case in in-house > libraries, or in a product that is split into independent modules. A more > frequent case is the deprecetation of a method, whose calls need to be > updated to another method which is usally semantically compatible (and > therefore a good candidate for a user-configured automated refactoring) > > Currently in build #638, it seems to be necessary to have the source code of > class X added into the project to be able to update dependencies after a > change to class X. It would be desirable to be able to do so with an > external class. One possible UI integration would be to enable the rename, > move refactoring even when no element (class/method) is selected and to ask > the name of the external class/method to refactor. > > Guillaume. > _______________________________________________ Eap-features mailing list [EMAIL PROTECTED] http://lists.jetbrains.com/mailman/listinfo/eap-features
