|Resolving proxies for Java types fails when model is loaded externally [message #1209039]
||Mon, 25 November 2013 09:56
| Till F.
Registered: August 2012
certain proxies in my language cannot be resolved if I load my language from another plugin. This affects proxies for Java types only (e.g. JvmDeclaredType). Within the Xtext editor everything works fine (scoping, linking, proposals etc.). My setup is somewhat complex already, thus I'm trying to give you a brief summary of anything that should be related with the problem:
- My language uses importURI to "include" other language files
- This (importURI) is bricked, when the TypesGeneratorFragment is activated (because TypesAwareDefaultGlobalScopeProvider is used as IGlobalScopePriver then)
- But I also want to include Java types support. However, I don't need/want to use Xbase, since I have my own expressions, etc.
- ==> My solution was to
-> enable the new scoping and exporting API as well as the TypesGeneratorFragment (as if Xbase were used)
-> but override the binding of IGlobalScopeProvider so that ImportUriGlobalScopeProvider is still bound
-> and handle Java types manually using TypesAwareDefaultGlobalScopeProvider that is also bound in the RuntimeModule by myself
This has enabled mit to refer to any Java element in the environment by using grammer rules and a custom scope provider like below, but also leaves importURI intact.
'jimport' importedType=[JavaTypes::JvmGenericType|FULLQUALIFIEDNAME] ';'
// PTSpecJavaScopeProvider derives from and uses members of TypesAwareDefaultGlobalScopeProvider
private PTSpecJavaScopeProvider _pTSpecGlobalJavaScopeProvider;
public IScope scope_PTSJavaImport_importedType(PTSRoot root, EReference ref)
return _pTSpecGlobalJavaScopeProvider.getScope(root.eResource(), ref);
public IScope scope_PTSActualJElement_jElement(PTSContainer container, EReference ref)
// calculates scope (list of JvmIdentifiableElement) based on 'jimports' above
This however stops working if I load the language file from another plugin using the following code (i.e. references to Java elements are unresolved proxies; e.g. PTSJavaImport_importedType or PTSActualJElement_jElement).
public static PTSRoot loadFullPTSModel(URI platformResourceURI) throws IOException
ResourceSet emfResourceSet = new ResourceSetImpl();
Resource emfResource = emfResourceSet.getResource(platformResourceURI, true);
EObject root = emfResource.getContents().get(0);
// above is called like this ("platform:/" URI is used)
URI ptsResourceURI = URI.createPlatformResourceURI(myFile.getFullPath().toString(), true);
PTSRoot root = PTSpecUtils.loadFullPTSModel(ptsResourceURI);
Surely I could check .eIsProxy() at corresponding places and try to get the JvmType using IJvmTypeProvider.findTypeByName(fqn) manually; but I think it shouldn't be necessary. What could be wrong with my setup above that resolving does not work automatically (and only when "used" from another plugin than the UIModule of my language)?
As already mentioned there are several other links to external resources that needs to be resolved as well (importURI related but also links to plain EMF models) - and in this case everything goes well irrespectively of how the model is loaded.
[Updated on: Mon, 25 November 2013 16:48]
Report message to a moderator
Powered by FUDForum
. Page generated in 0.01677 seconds