|
|
Re: Load models of imported Ecore in Xtext Language Server [message #1855815 is a reply to message #1855642] |
Fri, 04 November 2022 12:32 |
Byron Trollip Messages: 4 Registered: April 2022 |
Junior Member |
|
|
Thanks for the response Christian.
After attempting the approach to manually manage the loading of the XMI models in a custom LanguageServerImpl, we changed our approach to instead base our solution on the TypeFox blog post - Linking Xtext Models With EMF Models found at https://www.typefox.io/blog/linking-xtext-models-with-other-emf-models
We first tried the naive approach that you mentioned by "hacking" the Xtext builder mechanism before realizing that we could not easily extend the ProjectManager due to the Provider<ProjectManager> Guice injection that is used in the WorkspaceManager. Diving deep into the incremental builder code seemed to be the wrong approach in any case, for a functionality that is managed by Xtext with many complex moving parts.
The solution provided in the TypeFox blog post - Linking Xtext Models With EMF Models required us to implement a new Gradle subproject containing the "glue code" to register XMI as a language. This subproject is provided as a dependency to our language server, alongside our grammar subproject. This separation of concerns kept things clean in our grammar project. The XMI language subproject provides a language definition in a custom XmiRuntimeModule as well as registering a resource service provider for *.xmi files in a custom XmiStandaloneSetup. Lastly, we had to add an entry for the XmiStandaloneSetup in a META-INF/services/org.eclipse.xtext.ISetup, so that Xtext can "bootstrap" the XMI language at runtime.
Since the XMI language subproject is not concerned with the contents of any XMI file, we left the work to resolve the EPackage of any loaded XMI documents to the model consumer, in this case the Xtext grammar project, which registers all the required EPackages.
A drawback of this approach is that the XMI files containing the models need to be present as files in the workspace, as discovery of XMIs in JARs did not occur. This is slightly annoying, but we could live with this downside.
If you know of any way to have Xtext scan the contents of JARs in the workspace for registered language file extensions, it would be appreciated.
|
|
|
Powered by
FUDForum. Page generated in 0.03490 seconds