Community
Participate
Working Groups
This is actually an issue that appeared in the CDT, and I am trying to come up with a strategy to resolve https://bugs.eclipse.org/bugs/show_bug.cgi?id=151005 C compilers may generate error messages for files which are not workspace resources. The CDT error parser generates problem markers for them using the project which was being compiled. Therefore the standard "Go To" action (or, double click) in the Problems view fails: A project cannot be opened in an editor. We would still like to get the file opened, in which the error occurred. Here is a resolution strategy I would like to put up for discussion: 1) For errors in workspace-external files the CDT defines an extra marker type. The new marker type carries extra attributes which hold information about the external location of the file which contains the error. The CDT error parser generates markers of this type when an error in a workspace-external file is reported by the compiler. 2) For the new marker type a new action is contributed which will evaluate the extra information and open the workspace-external file. This is possible even today by making a popupMenu objectContribution and thus augmenting the problem marker's context menu. Now here is my issue: The Problems view's default action upon a double click is to open the workspace file that is referenced in the marker. This action cannot be changed. It is all hard-coded in the ProblemView's framework. I would suggest to have the openAction marker-type specific so that the default would be implemented in ActionOpenMarker as it is now, but that for certain marker types a different action could be contributed (via extension point or API)
I think what would make the most sense is an addition to the markerSupport extension point - perhaps we should add something like a markerActionMapping that maps an type to an action.
Another possible way to solve this problem is to fix bug 22284.
(In reply to comment #2) > Another possible way to solve this problem is to fix bug 22284. Sounds like a silver bullet: Very elegant, but extremely hard to come by. (The bug has been open for years but nobody fixed it) It sure is outside the range of my (CDT) competence.
This is also an issue with a view - we should solve it at the UI level not the core level.
I see the issue with both our commercial app and open source FindBugs project. In our commercial app (www.verigy.com) we have huge in-memory resources which cannot be mapped to any IResource (we can operate even without to have a single IProject in the workspace). This resources can hovewer have warnings/errors/etc markers, so we are doing extremely dubious operations to create and maintain "hidden" file structure in a "hidden" project => this is the only way we can re-use all existing "markers" views. Of course, this does not work well and we have multiple issues... In the FindBugs plugin (http://findbugs.sourceforge.net/) I'm currently trying to analyse jar/class files which are packaged inside war/ear/etc archives and I'm facing similar issues as in our commercial app... If jar is external, I can create a marker only for the project, but then the marker is absolutely meaningless within all the "markers" views (no sorting/no double click/no goto) and of course the marker is not shown in the (external) class file editor... Of course fixing bug 22284 would be nice thing, but considering amount of changes which would be needed, it is probably not realistic. What is about small but practical solution? I'm wondering if IMarker interface can be extended by adding URI information: "public URI getURI()" method can be used to provide ANY application specific address inside the marker. Additionally, a new "URIHandlers" extension point can be used to serve as support for editor/marker management within IDE (note that this handler is not bound to IMarker interface). possible URIHandler interface: /** * @return non empty array with the list of supported URI "sheme:" parts */ String[] getSupportedURIShemes() /** * (OPTIONAL, if getSupportedURIShemes() is enough) * @return non empty array with the list of supported marker types */ String[] getSupportedMarkerTypes() /** * (OPTIONAL, if getSupportedURIShemes() is enough) * @return true if the given location is supported by the handler */ boolean isSupported(URI location) /** * Open given location within the given page */ IWorkbenchPart open(IWorkbenchPage page, URI location); /** * Navigates to the given location within the given part */ boolean goto(IWorkbenchPart part, URI location); /** * @return human readable location description to show in the UI */ String translateForHumans(URI location); Having that, IDE.openEditor(IWorkbenchPage page, IMarker marker) can first check if there an MarkerHandler is available for given marker type/sheme/location, and then just redirect the call to the handler. The changes to the marker view's can also be minimal: even without the additional getURI() method, the ExtendedMarkersView.openMarkerInEditor() can check if marker's "location" attribute can be parsed as "URI" and if yes, check if there an MarkerHandler available for given uri, and then just redirect the call to the handler. What do you think about it?
