Implement workaround for EAttributes with high multiplicity on the M1 level

[Ulyana-F1re]

In LionWeb properties can be 0..1 or 1..1, but they can not have higher multiplicity (so 0.. or 1.. are not supported). In EMF ecore EAttributes can have high multiplicity. To support import of ecore metamodels with EAttributes of higher multiplicity, I updated EMFMetamodelImporter as following: we introduce an intermediate Concept that holds the property corresponding to the EAttribute, and this concept is added to the parent concept as a containment with high multiplicity.

Now we need to update EMFModelImporter and EMFModelExporter so that they are in synch with this meta-model transformation, so that we have a bi-diractional mapping between the original EAtribute and the introduced auxiliary LionCore containment on the M1 level.

[ftomassetti]

Could it make sense to add an annotation on these "synthetic" concepts, so that we know they need special treatment when importing or exporting models?

[enikao]

I had to solve a similar problem with MPS references (0..1) vs. LW references (0..*), with the same approach. I also have annotations like @ftomassetti proposes, they are very helpful (especially for multiple import/export scenarios).

[Ulyana-F1re]

To me it looks natural to implement such model transformations (also the one from [#166]) in the ecore world, using for example Xtend. That's what I also do in Rascal: all model transformations between LionCore and Rascal, on the M1 and M2, are implemented in Rascal. Does it make sense to use Xtend here too?

[enikao]

I wouldn't use Xtend for anything but M2T transformations. For M2M, the only real benefit it brings over modern Java is memoization. But we'd introduce a dependency on a kind of "fringe" technology. Doesn't sound like it's worth the risk to me.

[dslmeinte]

And memoization is easy enough to implement in a GPL (even in a transparent way using HOFs) as well.