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
