Community
Participate
Working Groups
Build ID: 3.4 Steps To Reproduce: If you create a Project which links to a file in another Project, and/or create a nested Project over an existing Project. You can end up with multiple ways to access the same file through the Project Explorer, Navigator, etc. views. Each of these IFiles appears to then have its own metadata - local history, markers, etc. - which leads to odd inconsistencies when users access the same physical file from multiple workspace locations. For example: 1) Opening the same file from multiple places in the workspace opens multiple editors. These editors don't stay in sync as the user edits (which does happen when you open a new editor on the same File e.g. a compare editor or right click > new editor). 2) Each file appears to have its own local history. So you can edit a file in one editor window, edit it in another editor window, save each in turn, and end up with different (and inconsistent) local histories. 3) Each file has its own markers. CDT which needs to report compiler warning / errors back to the user needs to worry about which project is being built before setting markers. What currently happens is the user can end up with non-C Projects having CDT build errors. Whereas the files in the CDT project don't have error markers. Needless to say when the markers are cleared on the CDT project, they remain on the Files which are linked to / exist in the parent of the nested project 4) Opening editors from a Plugin. Currently any integrator who wants to open an editor based on a filesystem path has to add extra logic to open the correct file on find{Files,Containers}ForLocation(). 5) As noted in bug 158657, setting a breakpoint on one file, then hitting the breakpoint in the debugger can result in a different instance of the same file being opened. 6) Open Resource. The user uses Open-Resource to open a file. Depending on which instance of the File they open and edit, they will be altering one of the local histories of the File (as per point 2). More information: I can understand the need to have separate IFiles at the workspace level. I would just expect that, as they all map to the same location, that File metadata would be persisted globally to the file. The same file in multiple places in the workspace should be opening in the same shared editor.
I think that this should be fixed at the root cause - by disallowing project overlap as suggested by bug 245412 comment 4 (masking out the folder of the physically nested project from its container).
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag.
@Lars.Vogel@vogella.com: "If the bug is still relevant, please remove the stalebug whiteboard tag." I do not see a way to do this, could you reopen the bug and remove the label? As for the bug here: This is still very relevant (or even more relevant) with at least Eclipse 22.03! The specific circumstances that brought me here: Using a file search I get multiple matches in the same "physical" file: /some gradle root project/.project /some gradle root project/relative-path/some-java-subproject/.project /some gradle root project/relative-path/some-java-subproject/src/main/whatever.java for any search I get 2 matches: some gradle root project/relative-path/some-java-subproject/src/main/whatever.java (this one is very bad) and some-java-subproject/src/main/whatever.java (this is the only valid one) Opening the wrong match may have surprising unintuitive consequences: The editor may not function properly because the enclosing project is wrong or lacks a neccesary nature. -> in my case even worse: Eclipse (or the language plugin) added the nature to the "some gradle root project" project and thus corrupted the project "permanently". Is there ever a valid reason to show resources in any project other than the one with the shortest relative path (more specific project)? A few things of note (IMO): * even if the more specific project is closed, eclipse must hide the resource: I closed the project after all! * Lots of maven projects seem to use a parent pom/project approach - most often the sub projects/modules are nested within the parent project (on disk) * every Gradle project has it's sub projects nested within the root project and therefore is affected by this issue * every action tht may open files presents an opportunity for the user to get the wrong file opened and thus experience reduced IDE functionality or bugs.
(In reply to Christoph Obexer from comment #3) > @Lars.Vogel@vogella.com: "If the bug is still relevant, please remove the > stalebug whiteboard tag." > I do not see a way to do this, could you reopen the bug and remove the label? Project moved to Github, so please open a new issue here with the relevant information: https://github.com/eclipse-platform/eclipse.platform.resources/issues
Thanks for the info Lars! FYI: moved to GitHub in https://github.com/eclipse-platform/eclipse.platform.resources/issues/149
