Community
Participate
Working Groups
From the Javadoc: @deprecated as of 3.5, use the Common Navigator Framework classes instead I think it is save to mark for deletion.
New Gerrit change created: https://git.eclipse.org/r/147408
This is more than deleting deprecated API. We would also have to remove the 'Navigator' view. I presume that many clients reference that view in their plugin.xml. They can't see any deprecation warning regarding this and will be broken when we do this. So, at the moment a -1 from me. Maybe you can try to replace the 'Navigator' view contribution with the 'Project Explorer'. If so, I might change my mind.
Note that bug 550016 is not the real issue. The Navigator view is contributed with an ID and clients (like Show In) can use this. Another example are perspectives that add/contain the view. So, we can't remove that view contribution. As mentioned in comment 2 you could try to replacing the implementation with the Project Explorer.
(In reply to Dani Megert from comment #3) > Note that bug 550016 is not the real issue. The Navigator view is > contributed with an ID and clients (like Show In) can use this. Another > example are perspectives that add/contain the view. So, we can't remove that > view contribution. As mentioned in comment 2 you could try to replacing the > implementation with the Project Explorer. Are you saying we can never remove a view contribution we did? I would disagree, that is why we have a deletion policy and clients have two years to adjust.
(In reply to Lars Vogel from comment #4) > (In reply to Dani Megert from comment #3) > > Note that bug 550016 is not the real issue. The Navigator view is > > contributed with an ID and clients (like Show In) can use this. Another > > example are perspectives that add/contain the view. So, we can't remove that > > view contribution. As mentioned in comment 2 you could try to replacing the > > implementation with the Project Explorer. > > Are you saying we can never remove a view contribution we did? I would > disagree, that is why we have a deletion policy and clients have two years > to adjust. I'd say it depends. The problem with removing the view extension is that we have no way in the IDE to alert clients as there is currently no way to mark an extension as deprecated. At the point when we deprecated the code/implementation we should have sent a note that the Navigator view is deprecated and should be replaced. It also depends on the view. The Navigator view is there since 1.0 and I presume that many clients/products still refer to it. That's why I suggested to try to only replace the implementation/class provided in the extension.
(In reply to Dani Megert from comment #5) > I'd say it depends. The problem with removing the view extension is that we > have no way in the IDE to alert clients as there is currently no way to mark > an extension as deprecated. At the point when we deprecated the > code/implementation we should have sent a note that the Navigator view is > deprecated and should be replaced. Maybe we can send around this note for 4.13? And mark for deletion in the next release? This would give clients 4.14 plus 2 years. > That's why I suggested to try to only replace the > implementation/class provided in the extension. I don't like this. This would allow the user to open the same view (Project Explorer) via several entries. Also we would end of with more menu entries than necessary.
> Maybe we can send around this note for 4.13? Dani, WDYT?
(In reply to Lars Vogel from comment #7) > > Maybe we can send around this note for 4.13? > > Dani, WDYT? I suggest you raise this topic in our next call.
Approved by the PMC: Result: Send out send to cross that we want to delete the view, outdate the label with "Deprecate" and mark it for deletion. See https://wiki.eclipse.org/Eclipse/PMC
I continue to question whether such deletions actually serve the best interests of the community. Disruption requires the community to make corresponding changes and will tend to raise the question, is this something in which we should continue to invest given anything that is API now, might well not be API next release, and might well disappear entirely at some point. But that's just my opinion and I don't have a huge fact base...
(In reply to Ed Merks from comment #10) > I continue to question whether such deletions actually serve the best > interests of the community. Disruption requires the community to make > corresponding changes and will tend to raise the question, is this something > in which we should continue to invest given anything that is API now, might > well not be API next release, and might well disappear entirely at some > point. The API was deprecated in Eclipse 3.5 in 2009.
I regularly use the Navigator View (in addition to the Package Explorer). a) it allows me to see my bin files b) when I/Eclipse is confused as to whether a project is already imported but in an unexpected Working Set, the Navigator View gives me a simple answer. The only alternative for a simple filespace inspector is to force me to resort to the horrible Windows Explorer. (In reply to Lars Vogel from comment #11) > The API was deprecated in Eclipse 3.5 in 2009. I have no problem with the API going, but please keep the really useful UI which presumably was not deprecated in 2009.
(In reply to Ed Willink from comment #12) a) it allows me to see my bin files Your can use the project explorer for that. b) when I/Eclipse is confused as to whether a project is already imported but in an unexpected Working Set, the Navigator View gives me a simple answer. Your can use the project explorer for that, if not please open a bug. > I have no problem with the API going, but please keep the really useful UI > which presumably was not deprecated in 2009. See comment 9.
Commented here as well: https://www.eclipse.org/lists/cross-project-issues-dev/msg16914.html I use this navigator view very frequently for seeing my ./bin files - especially for using with the builtin disassembler. I am ok with the API going but I would like to have the Navigator view present. (I see PMC already approved this deletion - However, would request PMC to reconsider this decision) It is a definite -1 from my side
(In reply to Manoj Palat from comment #14) > Commented here as well: > https://www.eclipse.org/lists/cross-project-issues-dev/msg16914.html > > I use this navigator view very frequently for seeing my ./bin files - > especially for using with the builtin disassembler. > > I am ok with the API going but I would like to have the Navigator view > present. > > (I see PMC already approved this deletion - However, would request PMC to > reconsider this decision) > > It is a definite -1 from my side Same here, its very annoying to navigate to a bin/ folder with a file browser, to copy the file path of a .class file and then open that in Eclipse. Its much quicker to use the Navigator (since Package/Project Explorer hides bin/). Also its nice to see the directory structure of a project "as is" from Eclipse, from time to time is even necessary.
(In reply to Simeon Andreev from comment #15) > (In reply to Manoj Palat from comment #14) > > Commented here as well: > > https://www.eclipse.org/lists/cross-project-issues-dev/msg16914.html > > > > I use this navigator view very frequently for seeing my ./bin files - > > especially for using with the builtin disassembler. Did you try removing the "Java output folder" filter in the project explorer?
I guess that works, thanks. Had no idea the Project explorer has a filter that I can turn off (since I could never find one in the Package Explorer).
(In reply to Simeon Andreev from comment #17) > I guess that works, thanks. Had no idea the Project explorer has a filter > that I can turn off (since I could never find one in the Package Explorer). Another hint for me that our filter icon is horrible if even experts like you do not find our filters. I see this with my customers all the time, nobody see the current icon and thinks: "Hey, I can adjust the filtering here". @Everyone: Please upvote Bug 465914 if you also think a better icon would have helped.
But as Dani mentioned and as noted in the mailing list, users actually use it, though generally there are good alternatives indeed, i.e., I didn't know I could ask to see the bin folders. :-P
(In reply to Ed Merks from comment #19) > But as Dani mentioned and as noted in the mailing list, users actually use > it, though generally there are good alternatives indeed, i.e., I didn't know > I could ask to see the bin folders. :-P I see several possible enhancements here: 1.) Change the default in project to show output folders -> Please open bug if you think that is useful 2.) Find a better filter icons which actually tells people that they can adjust filters -> Please upvote Bug 465914
While I like the Project Explorer and its flexibility to easily hook-in extensions and hide the usually not required stuff, I also find the Navigator view really helpful to quickly get an unfiltered view of the real filesystems that is not cluttered with virtual entries. I use that rather often, so I would also vote against the deletion of that view. I know about the filter option, but I would not like to have to switch a bunch of filters off or on just to get an almost "native" view on the filesystem. It is much easier to just open the Navigator in such a case. Regards, Michael
(In reply to Lars Vogel from comment #13) > (In reply to Ed Willink from comment #12) > > a) it allows me to see my bin files > > Your can use the project explorer for that. I've never really tried the Project Explorer except by accident. Just did, after changing a couple of filters about the only thing 'wrong' appears to be a failure to sort folders alphabetically, so "bin" appears way below "src". Therefore the Navigator View would appear redundant code-wise, but not use-wise. We perhaps just need an alternate standard customization of the Project Explorer that defaults to a tell-it-how-it-is filesystem view. Currently the Project Explorer is about four customizations away. This standard customization could be called the Navigator View to minimize user/documentation surprises.
(In reply to Ed Willink from comment #22) > We perhaps just need an alternate standard customization of the > Project Explorer that defaults to a tell-it-how-it-is filesystem view. +1
(In reply to Lars Vogel from comment #16) > (In reply to Simeon Andreev from comment #15) > > (In reply to Manoj Palat from comment #14) > > > Commented here as well: > > > https://www.eclipse.org/lists/cross-project-issues-dev/msg16914.html > > > > > > I use this navigator view very frequently for seeing my ./bin files - > > > especially for using with the builtin disassembler. > > Did you try removing the "Java output folder" filter in the project explorer? @Lars: hmm.. As others, I rarely used this Project Explorer. Thanks to your suggestion, now I can see the bin folder and .class files. However, this solves my issue partially only since I use Navigator view to compare .class files generated by javac as well to compare with that of ecj generated. Now, if I generate an X.class in src/ folder using command line javac from terminal, I don't see that .class file in Project Explorer - but I can see it Navigator view. Is there a solution for the above issue? I am ok for removal of Navigator View if a) Project Explorer has a way to solve the above as well and b) the suggestion of Ed Willink in comment 22 on a defaulting to tell-it-how-it-is filesystem view.
If we mark the view for deletion it does not mean that we will delete it. It just means that in two years we have the option. So I plan to continue with the "mark for deletion" as decided by the PMC. For the earliest possible deletion date after August 2021 (!!!), I created Bug 550379. Please create Bugs for your project explorer requirements and add them as dependency for Bug 550379. This way we can avoid that the view gets deleted as long as your requirements are not fulfilled. As the navigator code is not maintained anymore and deprecated since a long time, it might break at some point. Please be prepared to contribute to your requirements.
(In reply to Lars Vogel from comment #25) > If we mark the view for deletion it does not mean that we will delete it. It > just means that in two years we have the option. Ok. Sounds fair. > So I plan to continue with the "mark for deletion" as decided by the PMC. > For the earliest possible deletion date after August 2021 (!!!), I created > Bug 550379. > Please create Bugs for your project explorer requirements and add them as > dependency for Bug 550379. This way we can avoid that the view gets deleted > as long as your requirements are not fulfilled. Have created bug 550385 for the Project Explorer requirement and as suggested have created a dependency for the bug 550379. Thanks!
(In reply to Manoj Palat from comment #26) > Ok. Sounds fair. > Have created bug 550385 for the Project Explorer requirement and as > suggested have created a dependency for the bug 550379. Thanks! Thanks, Manoj.
Gerrit change https://git.eclipse.org/r/147408 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=11a7468864251253c55f4d685848d2bd05542427
New Gerrit change created: https://git.eclipse.org/r/148351
Gerrit change https://git.eclipse.org/r/148351 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=67901d927a87c0315fb8d98ddb844977c5efa8d7
I find the Navigator view extremely useful to inspect the content of the filesystem in the context of a project view. I'd be gutted to see it go. Could do with a like-for-like replacement such as a "show filesystem" button in the Project Explorer which would have to disable all the virtual entries and all filesystem filters.
Same here. We use Navigator view regularly if we need to operate on near-file-system-level. Basically I agree with most people here: Either please don't remove Navigator view at all or provide an almost-file-system-view with similar functionality within another view (e.g. Project explorer). Thank you.
Ideally there would be a replacement view that's implemented using non-deprecated APIs, but is configured to present by default pretty much exactly what folks are used to seeing in the Navigator view. I.e., I don't think that all the users who are used to using the Navigator view will want to have to figure out (learn) how to reconfigure the Project explorer for that purpose. Moreover, if one can't have both a Project explore configured to show projects nicely filtered and structured as it is now *and* at the same time also have a different Navigator-like view configured differently to behave/look-like the Navigator view does now then I don't think users will be very happy...
(In reply to Ed Merks from comment #33) > Ideally there would be a replacement view that's implemented using > non-deprecated APIs, but is configured to present by default pretty much > exactly what folks are used to seeing in the Navigator view. See bug 550385.
The project explorer view does not provide flexibility of navigator view. If I need to exclude a particular class file from the generated packaging then I just rename the java file with an different extension so that the class file is not getting generated. The refactor > rename option in the package explorer allows me to change the name of the class but not the name of the file from A.java to A.kava.bkp. I use this feature to play around when researching where I have multiple versions of the same java file for different scenarios and behaviors when the file extension referring to the version. this allow the class not be generated for those files thus not treading on the foot of each other when working with @autowired classes.
