Community
Participate
Working Groups
The language name such as "org.eclipse.ocl.examples.xtext.essentialocl.EssentialOCL" is a long fragile string. Applications attempting to instantiate Xtext editors need to use this string, but there is no global constant that can be referenced from Java. Suggest that the AbstractXXXRuntime provide a LANGUAGE_ID constant.
see org.eclipse.xtext.LanguageInfo.getLanguageName() and the generated activator in the UI plugin. Is that sufficient for your use case?
I've also come across this need a few times. Neither LanguageInfo nor the generator UI activator is helpful when requiring this information in code of another plug-in. Further I think it would be great if we could use the language ID when accessing the IResourceServiceProvider.Registry.
(In reply to comment #1) > see org.eclipse.xtext.LanguageInfo.getLanguageName() and the generated > activator in the UI plugin. Is that sufficient for your use case? Thanks, these are helpful but not as helpful as they could be: The long cryptic constant ORG_ECLIPSE_OCL_EXAMPLES_XTEXT_OCLSTDLIB_OCLSTDLIB ensures that spelling errors can be compile-time failures, but a normalised name such as LANGUAGE_ID would be easier to use. Also the name is in an internal plugin. My specific use case is for activation of an editor in an embedded context where I do Injector injector = XtextConsolePlugin.getInstance().getInjector(EssentialOCLPlugin.LANGUAGE_ID); Composite editorComposite = client; //new Composite(client, SWT.NULL); editor = new EmbeddedXtextEditor(editorComposite, injector, SWT.MULTI | SWT.V_SCROLL | SWT.H_SCROLL); to pass the correct injector to the embedded editor. I don't appear to require the name in the non-ui plugin, so I can put a static method in XtextConsolePlugin to exploit the new constant. I suspect that there may be multi-grammar parsing applications that may benefit from the name in the non-ui plugin so I think my original suggestion is still worth doing.
