Community
Participate
Working Groups
XtextResourceSet extends ResourceSet which causes problems for traditional modeling applications that use ResourceSet. For instance, when opening an Xtext (text file) that uses JDT Types with the Sample Ecore Editor the types fail to resolve because in XtextResourceSetBasedProjectProvider.getJavaProject there is an instanceof test that fails and so no IJavaProject is identified. I have learned in my own code that it is a very bad idea to extend ResourceSet since it is too fundamental to EMF. Instead, I use a ResourceSet.eAdapter so that my enhanced ResourceSet can coexist with anyone else's and so that a ResourceSet created by someone else can be enhanced to support my functionality. Please consider reimplementing XtextResourceSet as a ResourceSet Adapter.
We don't even need an adapter, since the only thing we do is hooking the URIConverter, which can be set from outside. However, the fundamental problem is, that the JvmTypes need a context (IJavaProject) in order to work properly. Since the sample ecore editor doesn't know about this, the context won't be there and the types won't be resolvable.
Situation is a bit worse: We have two subclasses of XtextResourceSet: 1) SynchronizedXtextResourceSet synchronizes the access to the contents of the resource set. This has been introduced to get rid of race conditions during the Ecore model inference. 2) ResourceSetReferencingResourceSet needed for global scoping. I suppose these cannot be replaced by using eAdapters.
(In reply to comment #1) > However, the fundamental problem is, that the JvmTypes need a context > (IJavaProject) in order to work properly. Since the sample ecore editor doesn't > know about this, the context won't be there and the types won't be resolvable. Indeed, and so I have created an ActiveEditorXtextResourceSetBasedProjectProvider that falls back on locating the IProject of the active IEditorInput. (Very inelegantly this requires a Display.syncExec to access the main thread from a worker. Needs an EMF change to cache the IEditorInput in the EditingDomainResourceSet.) Anyway as a result I have a my JvmTypes displaying correctly in the Sample Ecore Editor, which hopefully enables me to use the same models in other modeling environments such as Acceleo. [However next winge/suggestion, with 50 odd JVM types, I get 50 off extra java:/Objects/... resources. Perhaps these should use at least one level of package hierarchy so that only one java:/... REsource is contributed.]
(In reply to comment #3) > (Very inelegantly this requires a > Display.syncExec to access the main thread from a worker. Needs an EMF change > to cache the IEditorInput in the EditingDomainResourceSet.) Bug 326493 raised to support IProject access in EMF.
*** Bug 273860 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > (In reply to comment #3) > > (Very inelegantly this requires a > > Display.syncExec to access the main thread from a worker. Needs an EMF change > > to cache the IEditorInput in the EditingDomainResourceSet.) > > Bug 326493 raised to support IProject access in EMF. Ed Merks helpfully pointed out that the URI allows the resource and so the project to be located. No EMF change needed.
*** Bug 366992 has been marked as a duplicate of this bug. ***
