Thursday, November 27, 2008

How to make an xtext language reference another by nsURI

In principle, Xtext allows two languages to refer to each other by means of the importMetamodel feature. If you specify the imported meta-model by means of a file URI, everything works out of the box. Unfortunately, file URIs are not suitable in many scenarios, so something less physical would be appropriate.

Due to a certain mismatch between the way openArchitectureWare (and thereby all the language's Xtend and Check files) and EMF access files and handle EPackage registration. The following describes the way to go in the version of Xtext that is shipped with oAW 4.3.1. Note that in TMF/Xtext we will provide easier support by means of classpath relative URIs.

Example

We consider the following two DSLs asl and bsl, where asl references bsl:

asl:
importMetamodel "http://www.example.org/my/bsl" as mybsl;
A:
(imports+=Import)*
(bs+=BRef)*;
Import:
"import" file=URI;
BRef:
"a" name=ID "b" b=[mybsl::B];

bsl:
B:
"b" name=ID;
To allow such cross-language reference, you have bsl has to be installed in the workbench you use for editing asl.

Install an xtext language

This usually boils down to deploying the language plug-in into the Eclipse workbench, e.g. by exporting it as deployable plug-ins and fragments into the dropins folder of the Eclipse installation.

There is one issue with the way xtext registers its meta-model. The EPackage is added to the EPackage.Registry programatically in the generated MetaModelRegistration class, such that we can call it inside or outside a running Eclipse. If running inside Eclipse, the MetaModelRegistration is called by the Activator of the language plug-in. This can be too late, as other plug-ins might not use the language but the meta-model, and rely on it to be accessible from the EPackage.Registry.

We cannot use EMFs dynamic_package extension point, as it requires the ecore file to be in a plug-in neutral folder. This is not the case in Xtext, as it stores the generated file in a source folder, which is no longer present once the plug-in is deployed.

There are two ways to solve this problem
1) Run the EMF generator to generate code from the ecore model. This will also register the generated EPackage Java class to the generated_package extension point of EMF.
2) Register a proxy class to the generated_package extension point, that implements EPackage (empty methods) and returns MetaModelRegistration.getEPackage() as its eINSTANCE. To ensure that the model is really loaded, you should delete the registered proxy in the static initializer and set the right resource loader before registering the package.

org.example.bsl.EPackageProxy:
package org.example.bsl;
...
public class EPackageProxy implements EPackage {
static {
ResourceLoader cl = ResourceLoaderFactory.createResourceLoader();
try {
ResourceLoaderFactory
.setCurrentThreadResourceLoader(new ResourceLoaderImpl(
EPackageProxy.class.getClassLoader()));
EPackage.Registry.INSTANCE.remove("http://www.example.org/my/bsl");
MetaModelRegistration.register();
} finally {
ResourceLoaderFactory.setCurrentThreadResourceLoader(cl);
}
}

public static final EPackage eINSTANCE = MetaModelRegistration
.getEPackage();

public EClassifier getEClassifier(String name) {
throw new UnsupportedOperationException("Method not implemented");
}

// remaining methods of EPackage
...
plugin.xml:
  <extension point="org.eclipse.emf.ecore.generated_package">
<package class="org.example.bsl.EPackageProxy" uri="http://www.example.org/my/bsl">
</package>
</extension>

Referencing an installed xtext language by nsURI

The xtext generator starts a new plain Java VM, and therefore does not have access to EPackages registered via extension points. That's why you have to explicitly register the referenced metamodel of bsl in the generator workflow of asl. Into the bargain, we have to register bsl's resource factory. Write a class

RegisterBslHelper:
package org.example.asl;
...
public class RegisterBslHelper {

public RegisterBslHelper() {
EPackage package1 = org.example.bsl.MetaModelRegistration.getEPackage();
package1.eResource().setURI(URI.createURI(package1.getNsURI()));
org.example.bsl.ResourceFactoryRegistration.register();
}
}
and call it in the generator workflow generator.oaw:
<workflow>
<property file="'generate.properties'/">
<bean class="org.example.asl.RegisterBslHelper">
<component file="'org/openarchitectureware/xtext/Generator.oaw'" inheritall="'true'/">
</component>
</workflow>
Also make sure, that the my.asl plug-in has a dependency on my.bsl and reexports that.

3 comments:

Ilyas Keser's Blog said...

Hi Jan,

thank you for the posting about references to models of a different metamodel.

I created two Xtext projects (asl&bsl) with oaw 4.3.1 and installed bsl by running the EMF generator to generate code from the ecore model:
- create bsl genmodel (select mybsl.ecore->File->New->EMF Model->...)
- create model code (select mybsl.genmodel->generate modellcode)
- add org.eclipse.emf.ecore.generated_package extension to plugin.xml

Then, I expoted bsl project as "deployable plug-ins and fragments" into the plugins folder of my Eclipse installation.

To reference the installed bsl language I need the class org.example.bsl.ResourceFactoryRegistration (is used in your RegisterBslHelper class). But I can't find it in my generated sources. Is this class generated?

Thanks
Ilyas

Jan Köhnlein said...

Hi Ilyas,

sorry for the very late answer.

The ResourceFactoryRegistration has been introduced in oAW 4.3.1. It is automatically generatedby the Xtext code-generator.

Regrds
Jan

Patrik Nordwall said...

Jan, I need some help with this, see my question in oAW forum: http://www.openarchitectureware.org/forum/viewtopic.php?showtopic=11473
Thanks, Patrik