we have a model connector interface, that tries to identify the type of editors used, and select a common way to get the model. The setSelectionToViewer method is generally available in EMF generated tree editors, however is not available on their base classes, so as a workaround it is used via reflection.

However, this method should not be evaluated for the text editor from JaMoPP, as it is not a tree editor - possibly an application condition is written.

I tried to find the source code of JaMoPP and found the GitHub repository https://github.com/DevBoost/JaMoPP, but I couldn't find there the JavaEditor class, neither its registration to check why does it get selected.

Can you help where is this editor defined? It would help a lot to fix this issue.

Zoltan Ujhelyi wrote:
> I have installed JaMoPP, and the implementation should not find this
> editor for the model connector. This is clearly a bug.
Why should the implementation don't find this editor? I mean, I want to
query a Java model, that's why I open a Java file with the EMFText
generated JaMoPP editor. Thus, a Java file (or better a Java model) can
be handled as each EMF-based model, too. In this sense, what I've done
was opening the JaMoPP editor for my Java file and press the play button
in the Query Explorer to let the querying process. And so it did. I got
my results but I was wondering about this error when double-clicking a
result. You cannot assume that only tree-based EMF editors can be
queried because at least there might be EMFText or Xtext editors. From
my own experiences, I know that both EMFText and Xtext editors are able
to select EObjects. In my oppinion you should provide an extension point
where developers can register implementations of your model connector
interface to support more different editors. I could provide you
implementations for EMFText and Xtext.

> Can you please open a bug on Bugzilla for this issue?
Should I still open a bug?

yes, we have that kind of extension mechanism in place (no, there is no documentation yet, sorry), and the current implementations should support tree-based editors, Graphiti and GMF editors. Xtext editors are not supported, as we know of specific issues with regards to notifications (https://bugs.eclipse.org/bugs/show_bug.cgi?id=387119), that causes really hard to debug inconsistencies during editing. As of EMFText based editors, we have not encountered such before, so naturally we did not write explicit supporting code.

Alltogether, none of our current implementation can support explicitly the EMFText based editors, so the thing that an existing implementation kicks in and causes errors, is very clearly a bug.

I would like to have an open bug, as the general EMF implementation gets executed too often. If you are ready to provide an EMFText implementation, we would be glad to include it, however we cannot do it on eclipse.org because of IP rules (but we are ready to look for a way to support it). As of Xtext, we are not ready to support it, as of the previously mentioned issue, but it is possible to create the correct model connector for that as well.

Jan Reimann wrote:
> Hi guys,
> I just updated to Kepler. When I double-click a result in the Query
> Explorer Eclipse switches to the Error View and I get:
>
> NoSuchMethodException:
> org.emftext.language.java.resource.java.ui.JavaEditor.setSelectionToViewer(java.util.Collection)
>
> And indeed, the JavaEditor from (JaMoPP - EMFText) has no such method.
> But how can you assume that editors have such method? From which
> interface does it come?
>
> best regards,
> Jan
>