Community
Participate
Working Groups
Steps to reproduce: 0. Get a workbench with Project Explorer and "Link with Editor" enabled 1. Create a raw (non-Java) project 2. Create a file t.java in the project. JDT Editor opens the empty t.java file. 3. Click on another editor, and back in t.java. EXPECTED: t.java node selected in Project Explorer GOT: no selection in project explorer 4. From the JDT editor for t.java, right-click > Show In > Project Explorer EXPECTED: t.java node selected in Project Explorer GOT: no selection in project explorer Variations of the failure: * A variant of those steps to reproduce can be achieved by opening a .java from a JDT project, but with the .java file that's not under a source folder. Working variations: * Same actions with a .java file opened with JDT editor in a JDT project and with file under a JDT source folder work * Using another editor than JDT one (such as plain text editor) to open the .java file allows to get link with editor working. Code analysis: When opening a .java file with JDT editor, the JavaFileLinkHelper participates to resolution. Later, in CommonViewer.setSelection(...), update.getRefreshTargets() is used and returns only the working copy of installation unit, but the CommonViewer doesn't have any node for this CU and fails at selecting the file. When using on a non .java file or another editor, the JavaFileLinkHelper doesn't participate so it fails back to plain file resolution which works well. When inside opening a .java file that's inside a JDT source folder, the CommonViewer does has a node for the CompilationUnit and shows it. Remediation proposal: The JavaFileLinkHelper should only contribute for .java files open with JDT editor which are part of the build path (with a compilation unit existing in the CommonViewer).
Note that it could be the NavigatorPipelineService#interceptRefresh method which erroneously removes the file from the item to select, but I'm currently not able to understand whether it can be the source of the bug and am still in the idea that JDT is to blame so far.
*** Bug 364789 has been marked as a duplicate of this bug. ***
New Gerrit change created: https://git.eclipse.org/r/121215
(In reply to Eclipse Genie from comment #3) > New Gerrit change created: https://git.eclipse.org/r/121215 Is this patch ready for review?
(In reply to Noopur Gupta from comment #4) > (In reply to Eclipse Genie from comment #3) > > New Gerrit change created: https://git.eclipse.org/r/121215 > Is this patch ready for review? It is for the part about "Link With Editor", but the "Show In > Project Explorer" still doesn't work.
Please consider for M7, I see this error every day in my documentation projects in which I have lots of Java example file which are not in the build path.
(In reply to Mickael Istria from comment #5) > (In reply to Noopur Gupta from comment #4) > > (In reply to Eclipse Genie from comment #3) > > > New Gerrit change created: https://git.eclipse.org/r/121215 > > Is this patch ready for review? > > It is for the part about "Link With Editor", but the "Show In > Project > Explorer" still doesn't work. I think my answer wasn't clear. Is it ready for review -> Yes, this patch is ready for review as it fixes half of the request of this report.
Gerrit change https://git.eclipse.org/r/121215 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=236704724223312672b05ac1fc5525fb68240e75
(In reply to Mickael Istria from comment #7) > Is it ready for review -> Yes, this patch is ready for review as it fixes > half of the request of this report. Thanks, I have released this patch. We can set the target again once we have a patch for the other part.
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. -- The automated Eclipse Genie.
This still applies to 2019-12 and, together with bug #364600, makes it hard to deal with Gradle build files.
