Bug 425185 - The Sirius-Acceleo bridge should use the qualified name of the EClass during the validation
Summary: The Sirius-Acceleo bridge should use the qualified name of the EClass during ...
Status: NEW
Alias: None
Product: Sirius
Classification: Modeling
Component: Core (show other bugs)
Version: 1.0.0M5   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2014-01-09 07:37 EST by Stephane Begaudeau CLA
Modified: 2018-12-18 03:37 EST (History)
2 users (show)

See Also:


Attachments
bugzilla425185.model : models to reproduce the issue (125.94 KB, application/x-zip-compressed)
2014-01-10 05:45 EST, Alex Lagarde CLA
no flags Details
bugzilla425185.description : VSM to reproduce the issue (5.96 KB, application/x-zip-compressed)
2014-01-10 05:46 EST, Alex Lagarde CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stephane Begaudeau CLA 2014-01-09 07:37:26 EST
When you have a Java service in an odesign file, the Acceleo bridge will create an Acceleo module representing this service. For example, this class:

import a.b.c.d.MyType;

package a.b.c;

public class MyClass {
    public boolean doStuff(Lis<MyType> myType) {
        return true;
    }
}

would be "transformed" to this module:

[comment encoding=utf-8/]
[module myClass(<all the accessible meta-models>)]

[query public doStuff(myType: Sequence(MyType)): Boolean =
  invoke('a.b.c.MyClass', 'doStuff(a.b.c.d.MyType)', Sequence{myType})
/]

The problem occurs if the list of accessible meta-models contains two meta-models with the EClass MyType. Acceleo will take the first EClass accessible with the name MyType. The correct solution would be:

"[query public doStuff(myType: Sequence(myMetamodel::MyType)): Boolean ="

instead of

"[query public doStuff(myType: Sequence(MyType)): Boolean ="

This issue does not occur during the execution of the representation since the operation will be recompiled with the proper type. It only occurs during the validation of the odesign.
Comment 1 Alex Lagarde CLA 2014-01-10 05:45:47 EST
Created attachment 238854 [details]
bugzilla425185.model : models to reproduce the issue
Comment 2 Alex Lagarde CLA 2014-01-10 05:46:13 EST
Created attachment 238855 [details]
bugzilla425185.description : VSM to reproduce the issue
Comment 3 Alex Lagarde CLA 2014-01-10 05:48:02 EST
Steps to reproduce:
- Import the 3 projects contained in bugzilla425185.model.zip
- Launch a new runtime including those 3 projects
- Import the Viewpoint Specification project contained in bugzilla425185.description.zip
- Validate the VSM

=> Expecting one validation issue on the condtional style of bugzilla425185-oneCore Diagram, as the service isValidClass() is defined for bugzilla425185.EClass and not ecore.EClass
Comment 4 Alex Lagarde CLA 2014-01-10 05:55:23 EST
Hints for a fix:

- The class in charge of generating the module corresponding to a java service class is org.eclipse.sirius.common.acceleo.mtl.business.api.extension.JavaImportHandler
- in the createImport() method, it uses the signatures obtained from getPublicSignaresFrom() to generate the module by calling DynamicJavaModuleCreator.createModule()
- the issues comes from DynamicJavaModuleCreator.extractArgumentSignatureString() which does not use Eclass's package for the argument signature