How to do Acceleo code generation on in-memory model?

0
votes

I am trying to generate some code using Acceleo. I am constructing my model entity in-memory and I want to generate the code for it.

Now, when Acceleo tries to match my model object to the argument type of my template function, it does not match. The classes are exactly the same, but since the package registry of Acceleo and my in-memory model is different, they do not match and Acceleo says no matching model element could be found for the main template.

Can I correct this issue? Can I force the acceleo package registry to be the in-memory registry? Can I force class matching on a semantic level (instead of just on Java == ? )

2
javaeclipseacceleoocl
The nsURI used to register the package is http://mypackage.com/1.0/. The container of the class used by Acceleo is an EPackageImpl, while the container of the model class I pass is MyOwnPackageImpl. This shows that Acceleo is not using the same package registry as my runtime instance. – parasietje
Aha, when I use XMI compiler mode, Acceleo only gets a proxy! – parasietje
And the proxy URI used by Acceleo is file:///path/to/file.emtl#//mypackage/Object instead of http://mypackage.com/1.0/#/mypackage/Object. My module is properly defined as [module generateRCode('http://mypackage.com/1.0/')] in the MTL file. – parasietje
OK, I managed to attribute the correct URI. However, it still does not resolve correctly (still only gets a proxy) – parasietje
Thank you very much for your help Laurent. I will search a little on my own and will reopen a question if I am stuck on my search again :-) – parasietje

2 Answers

1
votes

Acceleo only registers models in its own registry if it can not be found in the global registry. Are you sure you are using the proper NsURI to register the package? The URI you set at the beginning of your Acceleo module ([module myModule('<NsURI>')]) must match the NsURI of your metamodel's root package. It must also match what you define in the registerPackages method of the java class generated alongside your main module (note that since you're creating your model in memory, this last step is probably not mandatory).

If these three match, Acceleo should be able to match the elements of your model with the types defined in the generation module. If it is not sufficient however, we'll need to know how you registered the package prior to creating your in-memory model?

Laurent Goubet Obeo

0
votes

To answer this question for anyone who comes along here:

The real issue was the URI of my EMF packages. I had a commons and commons.study package. The URI of the commons package was put as http://domain.com/model.ecore#/. Acceleo adds his own (blank) http://domain.com/model.ecore at runtime, which prevents the proxy resolver from delegating the request to the Workspace.

The solution was to rename my root commons package to the proper http://domain.com/model.ecore and to set the commons.study URI to http://domain.com/model.ecore#//study. This way, the Acceleo resource set will not contain a blank package, and delegates the loading correctly towards the Workspace package registry.

Please also note that your root package needs to be generated. If not, it is not registered correctly and will not be present in the Workspace package registry. So if the root package only contains a subpackage, add a DUMMY class in it as well.