Community
Participate
Working Groups
Since the transition from Acceleo 3.2 to Acceleo 3.4, all of my Acceleo files stopped working. I get an error that the meta-classes of the passed element and that expected by the template are incompatible. However, the types are well compatible or even identical. A further analysis showed that two different instances of the meta-model are charged, the one belonging to the passed element and the other belonging to the template. The error is probably a bit specific to my use case: the Acceleo engine is directly called by passing a UML model element from a Papyrus editor to it, i.e. the model is not charged via Acceleo. I tracked down the error to the following difference: the compiled EMTL files reference the UML2 plugin via a platform:/plugin URI platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore whereas the URI specified in the template is well http://www.eclipse.org/uml2/4.0.0/UML If I replace all URIs in the compiled code Acceleo works again (for me). A strange thing: if I specify an older version in the template, e.g. .../uml2/3.0.0/UML, the compiled EMTL contains the correct uml2/4.0.0/UML version instead of the platform:/plugin URI.
Hi, We have modified the way URI's should be resolved in a very specific use case which may be the source of your trouble. Does this problem appear with any UML based Acceleo generator? Stephane Begaudeau, Obeo
The problem occurs with all mtl files that use http://www.eclipse.org/uml2/4.0.0/UML as meta-model It happens with all UML files that I tried (when loaded into a Papyrus resource set)
Stephane, could you reproduce the problem? We can produce it on multiple machine here. steps to reproduce: Declare a module starting with [module TestModule('http://www.eclipse.org/uml2/4.0.0/UML')/] The EMTL compiler changes the MM URI to platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore
The problem can be reproduced, if an MTL file uses a profile that has been done for another UML version. In my case, the C++ profile was still a UML 2.4 profile whereas UML was already at 2.5. After profile migration, the problem went away. Thus, Acceleo seems to use a path to the plugin instead of the URI, if two different UML URIs are used (e.g. http://www.eclipse.org/uml2/5.0.0/UML for UML and http://www.eclipse.org/uml2/4.0.0/UML indirectly by the profile). Good to know finally, what caused the problem - since we can now avoid it. Not sure, if it is not a bug.
Glad to know that you found where the problem was coming from, I'm closing this issue then.
Ok to close, but the current Acceleo behavior is not helpful, since it *silently* makes a choice for the URI that causes the mentionned problem of incompatible arguments. Thus, I would prefer that Acceleo tells the user that there is a problem (different meta-model of profile and main meta-model), e.g. by means of a warning in the module header of an MTL file.
(In reply to Ansgar Radermacher from comment #6) > Ok to close, but the current Acceleo behavior is not helpful, since it > *silently* makes a choice for the URI that causes the mentionned problem of > incompatible arguments. > Thus, I would prefer that Acceleo tells the user that there is a problem > (different meta-model of profile and main meta-model), e.g. by means of a > warning in the module header of an MTL file. Acceleo does not make a choice here, it asks EMF for the metamodel matching a specific NsURI and then it saves the emtl file referencing the metamodel. EMF then takes care of the serialization. If the metamodel has been loaded in EMF with a platform:/plugin URI instead of the usual mechanism, EMF does not care, it supports it. We are just asking for the metamodel matching the NsURI declared at the top of the mtl file. If EMF gives us our metamodel, we are happy and then we ask EMF to save the emtl model. We are not loading the metamodel manually from the plugin with a platform:/plugin URI. If the UML metamodel is incorrectly referenced/resolved in an UML profile, we will use what is registered. > I would prefer that Acceleo tells the user that there is a problem (different > meta-model of profile and main meta-model) Acceleo is generic, it does not know what UML profiles are and you could have an odd metamodel URI for your use case and it could work without issues.
I don't understand why this is CLOSED INVALID. Perhaps it is CLOSED DUPLICATE 360926. Because Acceleo tooling operates in both Equinox and standalone domains and passes URISs between them, it must use a form of URI passing/resolution that is compatible in both domains. The EcorePlugin.ExtensionProcessor can probably do this now. The OCL StandaloneProjectMap does this and can go further by actively combating/diagnosing metamodel schizophrenia.
For the specific case of http://www.eclipse.org/uml2/?.0.0/UML the nsURI means the registered i.e. compiled Java metamodel, and since Eclipse UML2 only supports one compiled UML metamodel all legacy UML nsURIs are mapped to the one UMLPackageImpl and so should beend up normalized to http://www.eclipse.org/uml2/5.0.0/UML in all xmi:id references. For the specific case of platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore there is again only one version available but it is logically a different model to the compiled Java model even though the compiled Java model loads its content from UML.ecore as a consequence of initialize-by-loading being set true in the genmodel. Profiles extend UML.modetamodel.uml which is http://www.omg.org/spec/UML/20131001 rather than http://www.eclipse.org/uml2/5.0.0/UML and so we have the uncomfortable situation that the UML meta-level has a different nsURI to the model's tooled metalevel. The Eclipse UML2 API seems to do a good job of correctly converting between the meta-namespaces so that users are unaware of the specification/implementation distinction. This is potentially very dangerous and very easily undermined by careless conversions, such as one that I'm currently fixing in the Eclipse OCL pivot support. Getting this right requires absolutely precise URI resolution without any helpful heuristics.
(In reply to Ed Willink from comment #9) > such as one that I'm > currently fixing in the Eclipse OCL pivot support. Is there a bug for this problem? I ask because I'm currently having problems where a comparison within OCL fails apparently because there are two instances of a model loaded. I'm still trying to work out what is happening, but if there is a reference for what you are currently looking at I could see if it is related.
(In reply to Ed Willink from comment #9) > For the specific case of > > http://www.eclipse.org/uml2/?.0.0/UML > > the nsURI means the registered i.e. compiled Java metamodel, and since > Eclipse UML2 only supports one compiled UML metamodel all legacy UML nsURIs > are mapped to the one UMLPackageImpl and so should beend up normalized to > http://www.eclipse.org/uml2/5.0.0/UML in all xmi:id references. > > For the specific case of > > platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore > > there is again only one version available but it is logically a different > model to the compiled Java model even though the compiled Java model loads > its content from UML.ecore as a consequence of initialize-by-loading being > set true in the genmodel. > > Profiles extend UML.modetamodel.uml which is > http://www.omg.org/spec/UML/20131001 rather than > http://www.eclipse.org/uml2/5.0.0/UML and so we have the uncomfortable > situation that the UML meta-level has a different nsURI to the model's > tooled metalevel. The Eclipse UML2 API seems to do a good job of correctly > converting between the meta-namespaces so that users are unaware of the > specification/implementation distinction. This is potentially very dangerous > and very easily undermined by careless conversions, such as one that I'm > currently fixing in the Eclipse OCL pivot support. > > Getting this right requires absolutely precise URI resolution without any > helpful heuristics. Looks like you have a better understanding of what is going on than us in the case of profiles and UML.ecore, we would definitely welcome any patch and assist to get it in.
