I think there is a definite UML2Ecore issue in not suppressing EMF validation diagnostics wrt duplicates annotations. But it may require an EMF bugzilla to provide the extensibility for a UML2 override.
I didn't try a generation despite the validation errors. I expect the Stereo2 corruption goes away, but the Child override may need a UML2 JET template fix. Ow!
Raising a UML2 Bugzilla for the validation problem with a duplicates is probably the best way to get Kenn Hussey's opinion on this topic.
Hi,
Sorry I forgot to remove the embedded profile definition (I accidentally clicked on “yes” at save time in Papyrus), but
it is not interpreted by the UML2Ecore process.
The ecore model I provided you was generated restarting the workflow from scratch (after deleting the genmodel) without
modifying the options. So except if last-used options are saved elsewhere (in preferences?), the numerous "DISCARD"/"IGNORE" are the default one!
I guess that default options provide are result equivalent to the original Ecore genmodel generator.
Anyway, I agree that “PROCESS” provides a much better ecore.
Unfortunately your attachment has been blocked by our mail policy. I’m sorry to ask you, but could you try to re-send
it after having deleted the .class files? (Normally not embedding the the ./bin directory is ok, or “project clean” with disabled auto-build ).
But can we already conclude that there is something wrong in the tooling?
And what should I do to go further?
I understand from what you said :
-adding an “Extend association” + subsetted properties in subclasses
-setting UML2Ecore options to “PROCESS”
-manually removing name corruption (restoring initial name) in generated ecore model
-generating code without taking care of EMF validation errors
leads to a correct code generation. Right?
Do you think we could try to open a bug so that it work this way (at least for Stereotypes?)
Hi
(Pictures are nice to complement a discussion, but the project is the unarguable truth.)
We need to avoid getting meta-levels confused.
For regular features duplicates must be resolved.
base_XXX is a meta-feature, just like eClass(). There is only one. Multiple eClass()es do not need renaming because they have a virtual method to unify them. base_XXX must also be unified at the implementation level. This can be achieved by correct declarations/implementation
of e.g. getBase_XXX(). Using a regular feature gen-option to fudge a meta-feature may find a fortuitous one that works at the expebse of imposing that fudge on regular features.
Using your model, the *.uml looks good but there is an embedded Ecore profile definition which provides excellent opportunities for confusion. Your TestProfile.ecore is clearly bad; there is no derived unifying base_Element. After deleting the embedded profile,
the genmodel fails to load. Reloading the genmodel reveals a disturbingly large number of warnings against UML and also 2 relevant base_Element warnings.
This is because your genmodel has numerous "DISCARD"/"IGNORE". This demonstrates that tweaking options to suit base_Element breaks other UML functionality.
After changing to PROCESS all in the hope that this will be 'sensible', it loads fine and the *.ecore looks better; it has a Child duplicates, but Stereo2 is corrupted.
Generating code gives errors.
The attached ZIP has my manual attempt at correcting the generated code. Removing irregularities from Stereo2/Stereo2Impl is easy. Correcting ChildImpl is a bit harder. The inheritance is already ok. ChildImpl extends Stereo1Impl implements Child (extends
Stereo1, Stereo2). It inherits exactly one base_Element from Stereo1Impl. Just need to fix up the Stereo2 interface to re-use the Stereo1. I think that the eBaseStructuralFeatureID/eDerivedStructuralFeatureID changes solve this. (Not tested.)
Aargh. Removing the corruption at the Ecore level and we have the two "baseElement" problem, which persists even if they are declared to be derived; arguably an EMF bug, but not the kind of thing that will change in EMF now; I think I raised it a while ago.
But it's not an EMF bug, its a UML2 oversight. When UML2Ecore adds the "duplicates" annotation, it should also override the EMF validation so that the spurious duplicate diagnosis is not reported. Once the Ecore corresponds to the UML, the UML templates can
generate the correct code.
NB. The corrupt Stereo2 approach doesn't work in general. Suppose Stereo1 is defined by UML, Stereo2 by MARTE, both should be generated uncorrupted. Now when My-UML-MARTE has a double inheritance I cannot suddenly require that the generated MARTE code is
changed. Only the My-UML-MARTE generation can change.
Regards
Ed Willink
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
