Community
Participate
Working Groups
Working with build id 200411170800. Example reproduction: 1. Create a plugin project that depends on org.eclipse.ui.workbench.texteditor. 2. Open org.eclipse.ui.texteditor.AbstractTextEditor (use ctrl+shift+T). 3. Open/go to the outline view, and click on the init method. 4. Notice how the implement indicator shows next to the init method in the outline view, but not in the source editor's vertical ruler.
Works for me using I200412011139 (tested with source and binary project).
Just tried with a clean install of latest integration build: 200412011139. Started with a brand new workspace. This is not working for me. Would you mind trying again with a clean install+workspace? BTW, don't confuse the folding widget with the implement indicator (I doubt that you are, thought I'd mention it just in case :-)).
which JRE are you using?
Was using JDK 1.5.0. Just tried chaning to 1.4.2_04. Same result... BTW, the VM used to launch eclipse is Sun's 1.5.0...
Created attachment 16306 [details] screenshot that show's the problem Just to prove I ain't crazy...
I don't think you're crazy ;-). The key is to have reproducible steps. If - for example - I take a new drop and an empty workspace I don't have any line numbers in the editor, however your picture does ;-) However, I am now able to reproduce with the following steps with a fresh I200412011139 installed into an empty directory using JRE 1.4.02: 1. start with empty workspace 2. File > New Project 3. Select "Plug-in Project" 4. Enter "Test" as name 5. Press Finish (allow to switch perspective) 6. open plugin.xml and add required plug-in: <import plugin="org.eclipse.ui.workbench.texteditor"/> 7. save plugin.xml 8. open type AbstractTextEditor (using Ctrl+Shift+T) ==> no override indicators. I suspect a problem with the AST which provides this info. Search occurrences and mark occurrences (once enabled via tool bar) does not work for most of the elements either, e.g. if I select a type in the import section it (Ctrl+Shift+U > Identifier and marking occurrences) works fine but if I select a method or parameter further down in the file it's not working. Ctrl+Shift+U > Identifier tells me that the Java element is unknown. If I open another type, e.g. CaseAction then everything works as expected.
I've been walking through alot of eclipse platform/JDT code lately and am quite often experiencing what you experienced within AbstractTextEditor. Some of the classes I open work fine (ie. show override indicators, let me browse into types they are using, ctrl+U, etc), but others do not. At one point the UI might be behaving OK for a particlur file, and at another point it may not for that same file. Hopefully a fix for this bug will also fix most/all of the other issues...
The AST bindings cannot be created since classes in the org.eclipse.text cannot be found. This is because this plugin is not listed in the Plug-in Dependencies container. Moving to PDE UI to investigate why this plugin was not added to the dependencies.
org.eclipse.ui.workbench.texteditor does not re-export org.eclipse.text, and that is why it is (and must not be) on the classpath of the plugin in question. Moving back to JDT/Core for final resolution. Jerome, the classpath is correct, so please resolve as you see fit.
To clarify, I meant to say that org.eclipse.text is NOT and must NOT be on the dev classpath of the plugin.
This bug proves otherwise: a plugin P that prereqs org.eclipse.ui.workbench.texteditor needs org.eclipse.text in its classpath, otherwise name resolution fails. Wassim, are you saying that P should also prereq org.eclipse.text ? Or are you suggesting that org.eclipse.ui.workbench.texteditor should reexport org.eclipse.text so that it is visible to P ?
I am not suggesting either actually. From a PDE and a runtime point of view, the plugin should not unnecessarily import org.eclipse.text, and org.eclipse.ui.workbench.texteditor is not in a position to re-export org.eclipse.jface.text(which in turn re-exports org.eclipse.text) to its clients. The unfortunate incident is that although the dev classpath for the plugin is complete, some type hierarchies are not complete and thus JDT/Core is unable to do the name resolution it needs to do.
Jerome, I don't think there is anything you can do here.
The AST contains the problems that would help the user to find out that the classpath needs to be fixed. These problems could be shown in the UI (I'm not sure how) when the AST is created. Moving to JDT Text to comment or dispose.
It would be weird if the user selects PDE Tools > Update Classpath... and later gets informed by JDT Text that the classpath is incorrect, especially because invalid classpath problems are normally reported as problems by JDT Core. Sorry but I have to move the bug back to PDE UI who introduced a classpath container who allows to work with stuff (i.e. projects) which is not in the workspace. While doing so important classpath information which otherwise is present gets lost, in this example the relationship from org.eclipse.ui.workbench.texteditor project to org.eclipse.text. Example: 1. import org.eclipse.text and org.eclipse.ui.workbench.texteditor as binary projects 2. perform steps 2 to 8 ==> works
So it's PDE's fault for introducing a classpath container that advanced self- hosting from the dark ages into the 21st century :-) The user has the option to import its plugin dependencies into the workspace, in which case this problem would not occur. Closing as no action is planned from PDE's standpoint.
I'm surprised that this bug is being marked as WONTFIX. If you look at the screenshot that I sent with the bug, you'll notice that the override indicator is displayed in the content outline but not the source editor. Clearly there is an inconsistency here. If the outline knows the method is an override, why can't the text editor?
>The user has the option to import its plug-in dependencies into the workspace, >in which case this problem would not occur. That's what I do and it works fine (old fashioned guys don't live on the edge of the 21st Century ;-) I see the following simple solution to this problem to reduce the frustration of users who run into this problem: 1) Since Java Core is not able to work with the given classpath (see comment 8) it should generate an incomplete classpath problem marker (on the project) as it does in other cases. 2) PDE warns the user when about setups like those described by this PR and suggests to import the plug-ins as binary projects. Fixing 1 and 2 shouldn't be that hard and I think would be good enough to close this bug as fixed. In order to really fix the problem Java Core could revisit the current notion of a classpath entry and introduce something like invisible (or non-API) property which tells to use the entry on the full build path to get the full Java Core functionality but which children can't be referenced in code. However, my opinion is that we do not want to this additional complexity.
Dani, I am not sure bells and whistles (eg. decorations/warnings) are the answer here. The classpath IS complete. The real issue is this: >If the outline knows the method is an override, why can't the text editor? why the inconsistency?
>The classpath IS complete. In my opinion it is not complete: even though PDE does know about the dependencies of org.eclipse.ui.workbench.texteditor, Java Core has no chance to know this if it is not inside the workspace. However, I think that's a thing that PDE Core and JDT Core have agree upon. Outline's override indicators are still Java model based while the ruler code is AST based: we do more and more stuff AST based (espacially when it comes to J2SE 5.0 support). So yes, we could (and probably sooner or later will) replace the Java model based implementation and as a result even show less information to the user in this bug's setup. And of course, as I pointed out in comment 6 all other AST based stuff, e.g. mark occurrences and Ctrl+Shift+U are affected as well.
>In my opinion it is not complete To correct my previous comment: Wassim is right, the classpath of the project is in fact correct but some items/projects listed therein are missing in the workspace.
So to reiterate... The classpath is correct. Anything more than that on the classpath will give the plugin direct visibility to code it is not supposed to have. This must not happen. Unfortunately in this case, this resulted in a busted type hierarchy. So this becomes an issue with what's in the Java search scope (ie. what's in the workspace) rather than the correctness of the classpath. However, this is all implementation details and the rationalization does not help the end user experience. In the long term, one idea might be for JDT to provide two flavors of lib classpath entries: one which the plugin code will have visibility to (as is the case now), and another type which the plugin code will not directly see but is there to complete the classpath for other JDT purposes (e.g. name resolution, etc.) Refer to my comments in bug 73957 for a more important scenario where such new support would be needed. As for this bug report, I will move back to JDT/Text. I suspect it will either: 1. be used to track and address the inconsistency between the outline and the editor - for better or for worse. In this case, it will be worse of course as noted in comment 20. OR 2. be resolved as dup of bug 73957, since the resolution of said bug will make this problem go away.
*** This bug has been marked as a duplicate of 73957 ***
