Community
Participate
Working Groups
We ran into this problem while investigating solutions for bug 54898. If you open an external Java file using the Java editor, you don't get the ruler. So if you set breakpoints in the file, you won't see the breakpoints in the editor. They will only show up in the Breakpoints view, thus making the debugging experience much harder.
Is this one going to be fixed in 3.0?
We might fix this during the bug fixing phase (time permitting) but before we need to agree with Debug how/where breakpoint information is stored for non-resources.
Although this bug was not marked as fixed, I was recently pleasantly suprised to see that I can set breakpoints on an external Java file without problems. Dani, did you fix this or was it divine intervention?
no ruler yet. you probably selected a file that's already inside your workspace.
This problem also used to occur in any of the libraries referenced by the "External Plug-ins Libraries" project that gets created by PDE when you add external plug-ins to the Java search. This problem is now gone for some reason. Since nothing was done at your end, I'm guessing that the new implementation of the "Add to Java Search" functionality by PDE that is now based on containers may have inadvertently alleviate the problem.
no action for 3.0
I've run into this one recently working on the cfeclipse plugin. We've got a view that allows you to open files that are in the local filesystem, or on a remote FTP server. The lack of a vertical ruler is a bit of a PITA because folding doesn't work without it. I've already created an ExternalFile class that implements IFile, but I'm not totally sure what it is that kills the vertical ruler. Any pointers on what custom stuff I might need to add would be appreciated.
>I've already created an ExternalFile class that implements IFile, but I'm not >totally sure what it is that kills the vertical ruler. Please note that IFile is not intended to be subclassed and hence you might into trouble at several places.
How did the ant editor get error and warning annotations to work in external files in 3.1M3? Isn't that a similar problem?
The Java model does not work on/with external files and hence no problem reporting and no model operations e.g. to get the folding structure are possible. The Ant plug-in (model) probably (I did not check) accepts non-IFiles and can therefore generate problem annotations and structural info and hence it makes sense to show the ruler(s).
Thanks Daniel, I'm aware that IFile isn't supposed to be subclassed. Right now I'm investigating how the internals work to see if there's any way I can get the vertical ruler to come up. Once I have a handle on that I can hopefully see what it would take to do it 'properly' and decide if it's worth the effort. I'm happy enough not to have full support for model operations, but folding and line numbers would be pretty nice.
I've got the ruler and folding stuff working now with external files. The solution for anyone who wants to know was to create 3 new classes. ExternalAnnotationModel, ExternalMarker and ExternalFile. The model extends org.eclipse.ui.texteditor.AbstractMarkerAnnotationModel and replicates most of org.eclipse.ui.texteditor.ResourceMarkerAnnotationModel. ExternalMarker implements org.eclipse.core.resources.IMarker. It doesn't actually do anything in any of the methods, but an instance is returned by ExternalFile.createMarker(). ExternalFile extends org.eclipse.core.internal.resources.File. You're not supposed to do that and it may cause some bad things to happen, but other than that it works. If I could find a way to do it without needing to use File or something else you're not supposed to subclass, I'd be a happy man.
*** Bug 81182 has been marked as a duplicate of this bug. ***
Dani, what are the prospects of this issue being addressed for 3.1? This one is vital to the success of the new source lookup for debugging Eclipse applications (bug 65164)
Wassim, there are really two cases here 1) open an external Java file which for us means it is a *.java file, a *.class file or a *.jar which is not inside the workspace and not on the Java buildpath of a project. That's what this bug report is about. 2) stuf which is on the Java build path of a project (e.g. rt.jar) where the ruler is shown (if not it's different bug) and breakpoints can be set. Wassim, are you talking about case 1 or 2? Can you provide a step by step example/setup for the PDE problem? Showing the ruler is not the problem - the problem is to know where we have to get the annotations from. Darin, is Wassim's case supported and if so, where does Debug attach the breakpoints?
I am certainly talking about case 1. In Monday's build, we will release an SWT launcher which will clearly demonstrate the problem and will provide steps then.
The Java debugger supports breakpoints in files that are not contained in the workspace. In this case we assocaite the breakpoints with the Workspace Root resource. However, I just found that our support for breakpoint creation in external files is broken which is a regression that will need to be fixed :-(
Dani, let me give you a scenario using M5 on Windows: 1. Fresh workspace. 2. Check out org.eclipse.swt.snippets from HEAD. 3. swt.snippets comes in the form of a plugin which uses a PDE container. That is not the case for regular SWT projects. So go the Java Build Properties and remove the PDE container. Now also manually add the swt.jar to the project's classpath. It is located in the <eclipse_install>/plugins/org.eclipse.swt.win32_3.1.0/ws/win32/swt.jar. 4. DO NOT ATTACH SOURCE to swt.jar. (I doubt that you can locate the source for it anyways, since it is deeply hidden in another location ;-) 5. In the org.eclipse.swt.snippets package, open the Snippet101 java file and set a breakpoint on the fourth line in Main (table.setSize(...)) 6. Right-click on Snippet101.java and from the context menu: Debug > Debug As > SWT Application. 7. When you hit the breakpont from 5. Try to step into Table.setSize() 8. you will see that even though swt.jar has no source attached to it in the workspace, the launcher was smart enough to locate the source on the fly, and the debugger knew where to stop etc. I can do all the debug operations (step in/over, etc.) The only problem here is that there is no ruler. I can't set breakpoints. By extrapolation, we are planning on redoing the source lookup for debugging Eclipse applications in a similar way (bug 65164), so this ruler issue is a problem.
*** Bug 95254 has been marked as a duplicate of this bug. ***
Fixed in HEAD. Available in builds > N20060105-0010. The rulers (vertical, diff, line number and folding) are now there but looks as if it is not be possible to add breakpoints: as far as I can see this is not supported by Debug (note: the instruction pointer appears). Darin, is this true? See also bug 122743. NOTE: In my opinion the correct way to solve this issue is to find the source and actually attach it to the JAR. Then open the file. Why isn't it done that why? I'd assume that if the user can attach the source manually and PDE can find the source (as comment 18 proves) this should be doable.
We do support breakpoints in external files, but it was recently broken by disallowing breakpoints in remote files. See bug 120170.
