Community
Participate
Working Groups
As discussed in thread "Compare problem" of the platform newsgroup some time ago (see http://dev.eclipse.org/newslists/news.eclipse.platform/msg68505.html ), I have registered my own ContentMergeViewer and StructureMergeViewer via the "org.eclipse.compare.*" extensions points. I handle the comparison within the "setInput()" methods of those two viewers. The problem I have arises when an exception occurs within my comparison algorithms : a blank editor is opened, and the exception is logged in the error log. What I would like to do is to call for a basic text comparison when my comparison fails, or at least avoid the opening of a blank editor. Some way of cancelling the editor opening would be neat, some way of calling the textual comparison or creating a CompareEditorInput with the URIs of the files to compare, IStreamContentAccessors for those files, Streams containing the file contents or resourceNodes for the files would be even neater.
Could you take a look at StructureCreator#internalCreateStructure[1] method? I haven't checked it but it looks like there is a mechanism used when an error occurs. What kind of exception you are getting? It's not CoreException, is it? [1] org.eclipse.compare.structuremergeviewer.StructureCreator
A good starting point here would be to create mock viewers (both content and structure) which throw the errors you mentioned. From my observations I can see that a CoreException thrown from a structureMergeViewer results in an empty pane, I'm not sure what would you like to get here instead? We could hide the structure compare in that case, but I think it's better to leave it as it is so the user can easily see that something went wrong. Nevertheless, we have to take care about the contentMergeViewer issue. Any suggestions/patches are welcome.
Well, as mentionned in the description I first gave, I implemented both a StructureMergeViewer and a ContentMergeViewer, handling comparison in the ContentMergeViewer's "setInput" *or* in the StrucureViewer's content provider's "inputChanged". I fail to understand why the comparison with history set its input to the content viewer before setting the input of the structure viewer, whereas comparison from the package explorer does it the other way around. The problem here is : no exception is expected from either one of these methods, be it CoreException or any other. I'm pretty sure I'm far from clear about where I get my exception, further down is the stack *before* the exception is thrown with Eclipse paused in the process of a "Compare with => each other" (cut before going down to Platform#run() or other clearly insignificant methods. The problem is : at that point, compare does not expect an exception to be thrown and the compare editor is already opened (though blank). When such behavior arises, an exception is simply logged in the error log and the blank, partially opened editors stays on front. This is where I would like to cancel the opening, or even better, redirect the call to your own viewers. Indeed, the program I'm working on is EMF Compare (model comparison) and such behavior usually arises when the compared models cannot be loaded (an XMI file with XML syntax errors for example). And in such cases, text comparison would be better than a blank editor and a log :). This could be done in org.eclipse.compare.CompareViewerSwitchingPane#setInput(Object) : if "setInput" has failed on any of the viewers (catch RuntimeException ?) and the viewer is not the "default" for text comparison, try and swith to a TextMergeViewer. Does this seem possible to you or is this a totally impossible/error-prone/ridiculous suggestion :D? PS : behavior is the same in Eclipse 3.2, 3.3 and 3.4M4. Thread [main] (Suspended (breakpoint at line 202 in ModelStructureContentProvider)) ModelStructureContentProvider.inputChanged(Viewer, Object, Object) line: 202 ModelStructureMergeViewer(ContentViewer).setInput(Object) line: 247 ModelStructureMergeViewer(StructuredViewer).setInput(Object) line: 1606 CompareEditorInput$12(CompareViewerSwitchingPane).setInput(Object) line: 254 ResourceCompareInput(CompareEditorInput).feedInput() line: 690 ResourceCompareInput(CompareEditorInput).createContents(Composite) line: 524 CompareEditor.createCompareControl() line: 399 CompareEditor.access$2(CompareEditor) line: 369 CompareEditor$3.run() line: 326 RunnableLock.run() line: 35 UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 123 Display.runAsyncMessages(boolean) line: 3296 Display.readAndDispatch() line: 2974 Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 2389 Workbench.runUI() line: 2353 Workbench.access$4(Workbench) line: 2219 Workbench$4.run() line: 466
Hi, We've had no news on this issue either, do you have any plans to tackle this for 3.5? One of the most frequent question that comes up for EMF Compare is "how do we compare files as text if comparison as models fails?". A potential solution would be for org.eclipse.compare to provide an exception the contentMergeViewers / StructureMergeViewers could throw to tell "we could manage to compare those files, do it as text". Such an exception could be handled in CompareViewerSwitchingPane#setInput(object) (line 256 is where the input is fed to the viewers as per 3.5M3), and is also where our viewers throw generic exceptions such as NPEs for now. Another solution, maybe a little more difficult, would be to make the compare editor multipage, and to allow third-party viewers to show the "text" page if their own comparison failed. I know these might be too generic ... but there is no API as yet in compare to allow third-party plugins to fail gracefully and show the classic text comparison : we cannot simply deactivate our plugin.xml contribution of *MergeViewers as this isn't allowed by OSGI, so calling the comparison again when a failure arises will simply call our viewers and fail once more. We'd gladly try and implement something along those lines, but we'd need your input and ideas on what should be done before event trying.
(In reply to comment #4) We've been working on a big change in the compare editor (bug 169386). Compare editor enhancements is what we plan (among others) during M5. Please stay tuned.
Created attachment 123796 [details] quick and dirty patch for textual comparison Hi, Finally took some time to look into this issue a bit further. It looks like it won't be possible to "cancel" the opening of the compare editor once one of the ContentViewer or the StructureViewer (or both for that matter) threw an exception when setting its input. I then fell back to the first proposition I made in commment #0 : opening a textual comparison if my viewer fails (and that happens more than enough given we compare models and the metamodels can evolve ... but that's another issue). After a bit of searching (as in "digging" searching :p), I stumbled upon the code for the "compare as text" button of the binaryContentViewer : that's exactly the functionnality I am looking for. Neither CompareUI nor CompareUIPlugin provide any API for this. In fact, the Binary content viewer uses a trick to bypass all viewer searching by using CompareConfiguration's properties : Set set = new HashSet(); CompareEditorInput editorInput = (CompareEditorInput)compareConfiguration.getContainer(); compareConfiguration.setProperty(ICompareAsText.PROP_TEXT_INPUTS, set); set.add(editorInput); set.add(editorInput.getCompareResult()); This would be perfect to fix the issue event though this approach has some inherent problems (for one, we are forced to already have the comparison result to use this). The problem is : ICompareAsText is internal. Is there any chance ICompareAsText could be opened as API for third-party plugins to use? If not, could it be possible to add an API to allow for textual comparison from CompareUI? I'm attaching here a "quick & dirty" patch showing such API addition (built against HEAD, only tested on 3.4). Thanks for your time PS: the title of this bug could probably be changed
Hi, Just saw the changes committed on HEAD for the fixing of bug 266476 . This will fix our issue on the latest 3.5 builds. We'll be able to rely on reflective code to maintain downward compatibility for Europa. I still think allowing third party plugins to call for textual comparison of files through code would be a nice addition to compare, yet this will no longer be a blocking issue for us. I'll let you decide whether to close this bug and open a new enhancement request for textual comparison or not :p. Thanks again for your time and involvment :).
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.
