Description Stephane Begaudeau 2014-01-21 09:14:53 EST

Created attachment 239184 [details]
Projects showing the issue

For each Java services referenced from the odesign, the Acceleo bridge creates an in-memory version of the Acceleo module used to call the Java operations with a query.

In order to create this in-memory Acceleo module, the Acceleo bridge needs the NsUri of the meta-models used in the expression. The Acceleo bridge does not always create a valid in-memory Acceleo module for various reasons.

You can find an example attached, that will fail for two reasons.

I have two meta-models, the first one with a concept named "Foo", the second one with two concepts "Bar" and "Foo".
I have the following Java service:

package my.project.design.services;

import firstmetamodel.Foo;
import secondmetamodel.Bar;

public class Service {
	public boolean shouldBeUsed(Bar bar, Foo foo) {
		return true;
	}
}

and this is the in-memory Acceleo module created by the Acceleo bridge that will be sent to the Acceleo parser:
[module my::project::design::services::Service('http://www.eclispe.org/emf/SecondMetamodel','http://www.eclipse.org/sirius/1.1.0')]

[query public shouldBeUsed(dynamicParameter0:Bar,dynamicParameter1:Foo) : boolean =
invoke('my.project.design.services.Service', 'shouldBeUsed(secondmetamodel.Bar,firstmetamodel.Foo)', Sequence{dynamicParameter0,dynamicParameter1})
/]

There are several issues here:
1- The first meta-model, referenced in my odesign file is missing so the type "firstmetamodel::Foo" cannot be found. The list of the NsUris is created by looking at the packages of the parameters when the compilation is called, while it should look at what has been declared in the odesign by the end user who knows what meta-models he/she is using (so 'http://www.eclispe.org/emf/FirstMetamodel' is missing). Here the parameter is an instance of "secondmetamodel::Bar" so only the NsUri of the second meta-model is added in this module descriptor. I am pretty sure that we could retrieve the list of the meta-models defined in the odesign from the Acceleo bridge with things like the DDiagram or with the SessionManager (from what I've heard).

2- The types used here "shouldBeUsed(dynamicParameter0:Bar,dynamicParameter1:Foo)" are not using any qualified name, as a result it will never be able to successfully compiled with a proper second parameter like this "dynamycParameter1: firstmetamodel::Foo" instead of this "dynamycParameter1:Foo" which would be interpreted as this "dynamycParameter1: secondmetamodel::Foo".

The bugs in question should come from both of those classes:
1- org.eclipse.sirius.common.acceleo.mtl.business.api.extension.JavaImportHandler
2- org.eclipse.sirius.common.acceleo.mtl.business.api.extensionDynamicJavaModuleCreator

I have attached, the projects needed to reproduce the issue:
- in the workspace folder, the two meta-models with their edit and editor bundles and the viewpoint specification project
- in the runtime folder, the project containing my models and the modeling project showing the issue

The bugs in question will end up creating multiples "unresolved compilation errors" for Acceleo since the Acceleo parser cannot properly compiled those modules. It could also be noted that if an Acceleo modules cannot be properly compiled by the Acceleo parser, the compiled module should not be kept in cache by the Acceleo bridge which should log the error directly instead of trying to give it to the Acceleo engine which cannot do anything with it.