Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #267470 +++ Deprecated ResourceNavigator APIs should tell migration path. Deprecated API should always tell clients how to migrate to non-deprectaed alternatives, giving step-by-step instructions and/or concrete replacement classes/methods/ids. I didn't check all deprecations (unfortunately, they are not listed in bug 267470), but I came upon undocumented deprecations in /org.eclipse.ui.ide/schema/resourceFilters.exsd. And in IResourceNavigator, I would expect a reference to the ProjectExplorer and the org.eclipse.ui.navigator.resources plug-in.
This should be fixed for 3.5.
See also bug 268505.
Released to HEAD N20090324-2000, 35M6 In the original deprecation ofthe RN, all of the ResourceNavigator related APIs when deprecated referred to the Common Navigator Framework. The specific change for this bug is to add the reference in the deprecated extension point. The Common Navigator Framework includes documentation in the ISV guide, and part of that documentation shows how to use the CNF specifically for resources, which replaces the functionality of the RN. I don't think a specific reference to the ProjectExplorer in IResourceNavigator is necessary. I'm in the process of upgrading the CNF documentation in the ISV guide and as part of that upgrade will make sure the configuration of resources is clearly called out (as well as intergrating with the Project Explorer). Most of the content is there already, but it's in a section called using the CNF with RCP applications.
I understand that adding the same text (@deprecated as of 3.5, use the Common Navigator Framework classes instead) everywhere makes your life easier but at the cost of each developer that has to do the migration. If I encounter a type which is deprecated I expect in its Javadoc comment a link or at least doc how to replace it and same is true for methods.
(In reply to comment #4) > I understand that adding the same text (@deprecated as of 3.5, use the Common > Navigator Framework classes instead) everywhere makes your life easier but at > the cost of each developer that has to do the migration. If I encounter a type > which is deprecated I expect in its Javadoc comment a link or at least doc how > to replace it and same is true for methods. Sorry, I think that trying to explain how to replace the RN with the CNF is beyond the scope of something to try to do in the Javadoc. The CNF is a well known part of the system, and is pretty well (and will become more well) documented in the ISV guide, which is were people will look for it. I think the comments are clear and sufficient.
Unless there's a migration path, it's just wrong to deprecate the Resource Navigator. We need a Navigator-like view in the SDK, and unless there's a CNF-based replacement, this bug, bug 268083, and bug 268505 clearly show that it's either too early to deprecate the Navigator, or that you should keep this open until the existing functionality is available in the new framework (and remove the deprecations if it doesn't make it for 3.5).
(In reply to comment #6) > Unless there's a migration path, it's just wrong to deprecate the Resource > Navigator. We need a Navigator-like view in the SDK, and unless there's a > CNF-based replacement, this bug, bug 268083, and bug 268505 clearly show that > it's either too early to deprecate the Navigator, or that you should keep this > open until the existing functionality is available in the new framework (and > remove the deprecations if it doesn't make it for 3.5). > There is a migration path, the Project Explorer for example has been the default "Navigator" view in the Resource perspective since 3.4 (replacing the Navigator view). The CNF performs nearly all of the functions of the RN (there remains only bug 208801 [noted in the end of life plan] which will likely be fixed in 3.5M7). There are step by step instructions for using the CNF with resources (which have been in the ISV guide since 3.4, and will be greatly enhanced in 3.5). There is a clear end of life plan for the RN: http://wiki.eclipse.org/Platform_UI/ResourceNavigator#ResourceNavigator_end_of_Life which has been widely communicated (newsgroups, my blog, and eclipse-dev) and on which there has been no dissent (you are welcome to comment there if you like, since you have these concerns, I'm surprised you have not commented there previously). Regarding the specific bugs you mention: this bug - I believe I have have adequately addressed the issue here. bug 268083 - This has nothing to do with the deprecation of the ResourceNavigator and related classes, rather it has to do with providing the "resource navigator"-like functionality in the SDK, one option being contining to have the actual Navigator view which can certainly be implemented using the CNF, as explained in https://bugs.eclipse.org/bugs/show_bug.cgi?id=268083#c5 bug 268505 - If you look in that bug report, Dani and I have come to an accomodation to not actually deprecate the particular extension point given that it would cause the warnings (since the JDT UI needs to support that extension point forever, since it's part of the API0, but instead note in the documentation that it should not be used since the RN is deprecated. All of the RN classes will remain deprecated.
