Community
Participate
Working Groups
I've been relying more and more on the "Bookmarks" view in my exploration of the Eclipse codebase. It's a very handy feature that greatly helps navigation. Unfortunately I'm unable to place bookmarks inside a "binary" class, i.e. a class located inside a JAR, with source attached. I'm able to place breakpoints, but no bookmarks. Thanks!
Bookmarks are markers and therefore can only be attached to files. To be able to attach a bookmark to an entry in a Jar file we have to attach the bookmark to the jar with extra information of the actual bookmarked Jar entry. But the Bookmark viewer doesn't have support to do so. Nick, can you please comment.
Would need to generalize the notion of bookmarks beyond what core markers give use. There are no plans for the UI team to work on this defect until higher priority items are addressed. If you would like to work on this defect, please let us know on the platform-ui-dev mailing list.
There are no plans to work on this feature at this time.
*** Bug 62832 has been marked as a duplicate of this bug. ***
Hmm, from a users perspective there is not much of a difference between a .class file and a .java file. I can set breakpoints in both. But why can't I set bookmarks in .class files. (I understand the technical difference!) That means, I will have to continue to abuse breakpoints for bookmarks...
Reopening and moving to core to investigate
To be clear, the real problem is not simple .class files, but files within JAR files. In some cases, the JAR may be external to the workspace. Another way to express the request is to allow bookmarks/markers to be added to an arbitrary editor input. Two possible approaches are: 1) Generalize IMarker so that it can be applied to things like files within JARs files, files outside the workspace, etc (essentially to arbitrary objects). 2) Encode the editor input within an attribute on a marker attached to the workspace root. This is essentially the approach that is taken with breakpoints today. A mechanism exists for serializing editor inputs (used to persist editor state and in editor history). What's needed is an API for creating bookmarks with this serialized state included, and changes to the implementation of IDE.openEditor(IMarker) that would read that serialized state and create the appropriate input. Both approaches are non-trivial and since this bug has been open for three years it is clear nobody is interested in signing up to do this work. I'm going to close this bug as RESOLVED LATER (i.e., it's a valid request, but no committers consider it important enough to be worth the effort right now).
> 1) Generalize IMarker so that it can be applied to things like files within JARs > files, files outside the workspace, etc (essentially to arbitrary objects). It seems that this depends on bug 37723 (Support logical model integration). See also complaint 6 in http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-vcm- home/docs/online/team3.1/logical-physical-public.html
*** Bug 126992 has been marked as a duplicate of this bug. ***
Now that bug 37723 is fixed, does that help this one?
See also bug 111887. Use case: Right now I'm writing a builder which is generating markers based on some compiler output. Sometimes the compiler errors occur on files not in the workspace. Currently, I put the marker on the project itself and set the location to the real filename. (I guess I could just as easily set it on the workspace root as in comment #7). But, in 3.2RC1 down in org.eclipse.ui.views.markers.internal.ActionOpenMarker.run(), it has this code: if (marker.getResource() instanceof IFile) { try { IDE.openEditor(part.getSite().getPage(), marker, OpenStrategy.activateOnOpen()); } ... Also in org.eclipse.ui.IDE.openEditor(IWorkbenchPage, IMarker, boolean) it again says: // get the marker resource file if (!(marker.getResource() instanceof IFile)) { IDEWorkbenchPlugin .log("Open editor on marker failed; marker resource not an IFile"); //$NON-NLS-1$ return null; } Because my marker's resource is an IProject this fails. If these checks could be changed to test for something else, like an IFileStore or IStorage or IEditorInput, then at least I could make double-clicking in the problems view work, which is the main thing I need. John do you have any thoughts on this? Would anybody object if I reopen the bug? Or should I open a new one? I can contribute a patch given a little guidance about the best way to do it, if it can make it into 3.2 since that's the release I'm targeting with my plug-in.
Ed, you're welcome to open a new bug report. It sounds like what you want is the ability to delegate the open editor behavior for a problem marker. Unless there is some way to do this already, I think you're out of luck for 3.2. We are feature frozen for 3.2, and focusing now only on severe defects and documentation.
Please reopen for 3.3.
Could you please reopen this bug for 3.3. Thanks.
This is not being considered for 3.3.
Along the same lines as comment #10 - Now that bug 37723 is fixed, does that help 126992 (which was marked as a dup of this one)? What we're trying to do is get the same behaviour relating to markers in the Problems view for files in the workspace and files outside the workspace - ideally, a way to map an external file to a resource.
Reopened for 3.5.
(In reply to comment #16) > Along the same lines as comment #10 - Now that bug 37723 is fixed, does that > help 126992 (which was marked as a dup of this one)? Bug 37723 is about logical model integration support and doesn't help to set markers on external files. > What we're trying to do is get the same behaviour relating to markers in the > Problems view for files in the workspace and files outside the workspace - > ideally, a way to map an external file to a resource. You could map an external file using linked resources. (In reply to comment #17) > Reopened for 3.5. The initial comment was about adding bookmarks "inside a "binary" class, i.e. a class located inside a JAR, with source attached." Comment 7 says how we can proceed. I'm adding Darin to the cc list to ask if there is any effort planned in this area (solution 2 from comment 7). If we want to fix the general issue (external files, files within JARs) we need solution 1. Is anyone interested in working on the fix?
We map Java breakpoints to Java model elements by adding a special "Java element handle" attribute on each breakpoint marker. We have done nothing to provide a generalized solution for this, but would find it useful for "external" .java and .class files. Currently, it is possible to set breakpoints in external .java/.class files, but they do not appear in the vertical ruler (only in the breakpoints view).
(In reply to comment #19) > We map Java breakpoints to Java model elements by adding a special "Java > element handle" attribute on each breakpoint marker. We have done nothing to > provide a generalized solution for this, but would find it useful for > "external" .java and .class files. Mee too :-( I'm trying to add FindBugs warnings for classes located inside external jar files, but this is impossible today... > Currently, it is possible to set breakpoints > in external .java/.class files, but they do not appear in the vertical ruler > (only in the breakpoints view). Darin: what is the *techical* reason why they do not appear in the vertical ruler? What if IMarker interface would be extended by adding URI information: "public URI getURI()" - would this help here? See also bug 155379 comment 5 talking about how to open a custom editor for custom (non-IResource) location from problems view.
> Darin: what is the *techical* reason why they do not appear in the vertical > ruler? Dani, you probably konw the *technical* reasons better than me?
>> Darin: what is the *techical* reason why they do not appear in the vertical >> ruler? >Dani, you probably konw the *technical* reasons better than me? The problem is that when the breakpoint is created on the workspace root the needed information (Java element handle identifier) is not set because JavaCore.addJavaElementMarkerAttributes(Map, IJavaElement) is not called (I suspect). Debug should try to get the Java element and call the mentioned method. If so, the breakpoint should appear and most likely, the Breakpoint view would also show the correct element name like it does for "normal" breakpoints. >What if IMarker interface would be extended by adding URI information: "public >URI getURI()" - would this help here? I doubt as currently all marker related APIs are IResource centric.
(In reply to comment #22) > >> Darin: what is the *techical* reason why they do not appear in the vertical > >> ruler? > >Dani, you probably konw the *technical* reasons better than me? > The problem is that when the breakpoint is created on the workspace root the > needed information (Java element handle identifier) is not set because > JavaCore.addJavaElementMarkerAttributes(Map, IJavaElement) is not called... Is it a DEBUG issue then? I would leave this bug only for discussions and progress on making IMarker more general, see comment 7, point 1.
Sorry my previous comment 22 was wrong: the code in JavaCore is only for class files but the problem of missing breakpoints happens in *.java files outside the workspace. We either need this bug here fixed or add a special solution like we did for class files. >Is it a DEBUG issue then? No. This bug is requesting that markers can be added to non-resources.
(In reply to comment #24) > >Is it a DEBUG issue then? > No. This bug is requesting that markers can be added to non-resources. There is no doubt that this report is a request to generalize IMarkers (comment 23, 2nd paragraph). My question "Is it a DEBUG issue then?" was about your suggestion in comment 22 which was "Debug should try to get the Java element and call the mentioned method". However regarding comment 24, it seems DEBUG has nothing to do here. Thanks :-)
*** Bug 372072 has been marked as a duplicate of this bug. ***
Can this be revisited and addressed?
(In reply to Kelly McGraw from comment #27) > Can this be revisited and addressed? There are no plans to work on that but high quality patches are welcome.
*** Bug 471964 has been marked as a duplicate of this bug. ***
I have a new use-case and potentially new solution approach for this. Many of our users use Eclipse like an editor. They navigate to external files, or drag-and-drop them into the editor area, use the launcher --openFile. They would like to set bookmarks on such opened external files, such that they can quickly navigate there, as well as use the Task tags mechanism. What if a plugin installed an editor open listener, and automatically converted external files to Linked Resources ? It could create a dummy "External Files" project to hold those "auto-converted to resource" files. As a result, the user would get a history of recently opened files. Such files would participate in the global search, bookmarks and task tags. The plugin could cap the list of such "recently converted to resource" at, say 30 files (Preference setting). If the 31st external file is visited, the oldest one is unlinked from the project. What do people think, does such an "Auto-convert visited files to IResource" approach sound reasonable ? Does anyone know if such a plugin already exists on the marketplace (on a quick search, I didn't find one) ? CQ:WIND00-WB4-6259
(In reply to Martin Oberhuber from comment #30) > I have a new use-case and potentially new solution approach for this. > > Many of our users use Eclipse like an editor. They navigate to external > files, or drag-and-drop them into the editor area, use the launcher > --openFile. They would like to set bookmarks on such opened external files, > such that they can quickly navigate there, as well as use the Task tags > mechanism. > > What if a plugin installed an editor open listener, and automatically > converted external files to Linked Resources ? > > It could create a dummy "External Files" project to hold those > "auto-converted to resource" files. As a result, the user would get a > history of recently opened files. Such files would participate in the global > search, bookmarks and task tags. The plugin could cap the list of such > "recently converted to resource" at, say 30 files (Preference setting). If > the 31st external file is visited, the oldest one is unlinked from the > project. > > What do people think, does such an "Auto-convert visited files to IResource" > approach sound reasonable ? Sounds interesting.
I agree.
(In reply to Martin Oberhuber from comment #30) > I have a new use-case and potentially new solution approach for this. > > Many of our users use Eclipse like an editor. They navigate to external > files, or drag-and-drop them into the editor area, use the launcher > --openFile. They would like to set bookmarks on such opened external files, > such that they can quickly navigate there, as well as use the Task tags > mechanism. > > What if a plugin installed an editor open listener, and automatically > converted external files to Linked Resources ? > > It could create a dummy "External Files" project to hold those > "auto-converted to resource" files. As a result, the user would get a > history of recently opened files. Such files would participate in the global > search, bookmarks and task tags. The plugin could cap the list of such > "recently converted to resource" at, say 30 files (Preference setting). If > the 31st external file is visited, the oldest one is unlinked from the > project. > > What do people think, does such an "Auto-convert visited files to IResource" > approach sound reasonable ? Does anyone know if such a plugin already exists > on the marketplace (on a quick search, I didn't find one) ? > > CQ:WIND00-WB4-6259 I understand the current bug (or RFE) in more generic way - adding IMarker's on any kind of NON-IFile objects, like class entries inside jars or other in-memory structures. Your proposal sounds more as a subset of it (automatically create workspace resources for external files opened in editors)? Should it just go to the separated RFE? The problem with in-memory data is that it cannot be mapped to the file system easily, except we teach Eclipse to create and use in-memory file system (see https://wiki.eclipse.org/EFS) and link some folders in the special "External Resources" Eclipse project to such virtual file systems. I've not tried EFS yet, but probably a convenient API can be added to the resources plugin (I'm not sure if we have something already) which would provide clients an easy way to create, link and manage EFS based folders or projects?
(In reply to Martin Oberhuber from comment #30) This is an interesting idea that deserves a separate feature request. Please keep in mind that hosting the auto-linked files in the "External Files" project may be suboptimal in a number of cases. One such case is a single project in the workspace that has some project-level settings affecting editor appearance and/or behavior. In this case you would want to apply these settings to the auto-linked files too. Another case is files that were opened in a context of one of the workspace projects, for example a C++ header file opened by pressing F3 on an include statement. Yet another case is files in a subdirectory of a project folder but not included to the project due to resource filters.
