Community
Participate
Working Groups
RC4. I have http://www.eclipse.org/ocl/3.1.0/Pivot installed as a plugin with: TemplateableElement::unspecializedElement : TemplateableElement I have platform:/resource/org.eclipse.ocl.examples.pivot/model/pivot.ecore providing the 'same' NS URI, but with a migrated feature: Type::unspecializedElement : Type I have a module declaration of [module generateOclCommon('platform:/resource/org.eclipse.ocl.examples.pivot/model/pivot.ecore','http://www.eclipse.org/emf/2002/Ecore') and the module nominally compiles ok but hovering over [type.unspecializedElement.getSymbolName()/] shows [EReference] unspecializedElement : TemplateableElement [0..1] demonstrating that the editor is using the plugin resource rather than the project resource which was explicit on the module declaration. The EMTL and execution are consistently wrong. Execution fails since execution uses the project resource correctly with a broken EReference.
I have a similar problem using Acceleo 3.4.1. An MTL file references a UML profile with a valid registered URI pointing to a platform:/plugin resource. However, if the plugin defining the (static) profile is present in the workspace, the EMTL resource loader somehow transforms this URI into a platform:/resource URI. This implies that the ecore associated with profile is added to the Acceleo resource set and loaded a second time. The consequence is that eClass references within the model and those passed by Acceleo are not identical Java instances although its the same thing. This in turn implies that many functions related to stereotypes do not work correctly. The problem does not appear, when the EMTL file referencing the profile is loaded by means of a plugin:/plugin reference. It also goes away, if the plugin that contains the profile definition is closed.
Whereas the behavior I described above is somewhat linked to the one Ed described originally, I effectively wanted to add it to bug 351137. Sorry about that.
Our tests did not reproduce the issue described here and on top of that the use of "platform:/resource" or "platform:/plugin" in an Acceleo module to reference a metamodel is deprecated and it won't be supported anymore. Only the use of the NsURI will be supported.
I don't know how platform:/resource can be deprecOted. It is what I normally use in a variety of applications to ensure that I use the workspace rather than installed model.
The Acceleo module is not the place where the details of the location of the elements used by the compilation context should be specified. In the Acceleo module, the user should only defines what's needing for the compilation (I need the metamodel X) but not define where this metamodel should come from.
(In reply to Stephane Begaudeau from comment #5) > In the Acceleo > module, the user should only defines what's needing for the compilation (I > need the metamodel X) but not define where this metamodel should come from. That's a valid interpretation of the spec but then you need the approach taken by QVTo that support a project preference page that maps virtual namespace URIs to physical ones. Attempting to discover the mapping automatically is very costly and can give undesired results.
