Community
Participate
Working Groups
Background: Xtext supports a text view of Ecore models and successfully registers this view so that text can be used as Ecore, and opened in the Sample Ecore Editor. Xtext also supports resolution of text tokens to Java types. Problem: An Xtext text document with Java type references fails to resolve the Java types when opened in the Sample Ecore Editor. Diagnosis: The Java type resolution requires a suitable IJavaProject to provide the classpath for Java resolution. This classpath is not easily obtainable from the worker thread of a ValidateAction which may be the first occasion on which an attempt to resolve the Java reference is made. Workaround: The resolution code can use a Display.syncExec runnable to discover the IEditorInput of the active editor and use the Java class path of the corresponding IProject. Hazards: Issuing a syncExec from a worker thread to the main thread provides an opportunity for deadlock. Using global workspace state to rediscover local context is not in accord with e4 policies. Suggestion: Let the EcoreEditor createModel code cache the IEditorInput in a Resource Adapter and/or the IProject in the EditingDomain, so that application code can access it.
I have no idea what this is really asking for. There's no test case, nothing to reproduce a problem, nor anything that would let me verify that something we provide is the best solution to a problem. I don't even understand how the IEditorInput is important. As I understand it, you'd know the URI of each resource, if it's platform:/resource you'd know what project it was in, and you'd be able to figure out the classpath for the project. Why isn't that sufficient for classpath resolution?
Spot on. Thanks. The URI provides the correct bundle ..., rather than IEditorInput which was just a pretty good guess. Just need Xtext to provide the specific Resource rather than the whole ResourceSet.
