From element in mapping should include extended model elements

[Matthias Schoettle]

When selecting the from element in a classifier mapping, only the classes from the instantiated aspect are shown.

Steps to reproduce:

1. Open the Association concern
2. Make sure that the Association aspect has a reference to Collection (empty class)
3. Open the ArrayList aspect and in the instantiation for Ordered, create a ClassifierMapping and attempt to select the from element

The selector will only show |Data, but should also show classes from extended aspects higher up the hierarchy. This only applies to instantiations that are of type Extends.

[Matthias Schoettle]

Resolves #309: Adds classes from extended aspects to the from choice of values for ClassifierMappings.

→ <<cset b798bb44d4c4>>

[Matthias Schoettle]

This leads to the following problem:

Consider the Association concern and the following facts: There is a class Collection in Association and ArrayList (extends Ordered, which extends Association) maps Collection to ArrayList<...>.

If woven, the result will contain both Collection and ArrayList<...>, because after weaving ArrayList into Ordered, the mapping is lost.

I see two posibilities:

• we don't allow to select elements from other extended aspects. Instead, the extended aspect must propagate/delegate the fact that a concrete class needs to be provided for Collection (in line with the concern partiality)
• the weaver detects that an element from another aspect is mapped and adds that mapping to the extension of the aspect

@djeminy: What do you think?

[Jörg Kienzle]

Unfortunately I think we have to go with option 2. Otherwise, the designer of the "middle" feature, in our example "Ordered", would have to guess which classes could possibly be mapped in child features. In general I think this is not possible.

[Matthias Schoettle]

Hm, I thought it would be the same person, because it is within a concern (i.e., the concern designer).

[Matthias Schoettle]

References #309: Reverts commit b798bb44d4c43bbd6aa17f92a3dedf17a872a5b2.

Instead of showing elements from grandparents, the extended aspect needs to propagate the decision down to child features. This is ok, because it happens within a concern (i.e., the concern designer is responsible).

→ <<cset df65b7e4db0d>>

[Matthias Schoettle]

Unmapped operations (that are concern partial) from extended aspects should, however, be shown.

E.g., in Association the operations of Data are incrementally added throughout the hierarchy, and, in the leaf features, all operations are mapped to the actual operations.

[Matthias Schoettle]

Resolves #309: Adds all concern partial operations from extended aspects that are higher up in the hierarchy to be able to map them.

→ <<cset 5b0b87d5dfe3>>

[Matthias Schoettle]

As discussed in our meeting today, it should be possible to map elements within the extends hierarchy (within a concern). And the weaver needs to handle it accordingly. See #435 for more information.

[Matthias Schoettle]

I think it makes most sense to incorporate this into COREMappingItemProvider and make use of the ModelExtensions, so it requires the metamodel to be updated first.

[Matthias Schoettle]

See COREMappingItemProvider and COREModelUtil.collectExtendedModels(COREModel) or COREModelUtil.collectModelExtensions(COREModel).

[Matthias Schoettle]

References #309: Removes custom filtering as it is now done by COREMappingItemProvider in a generic way.

→ <<cset e31a2a3fe1a9>>

[Matthias Schoettle]

Resolved with above commit and core/3c9a105.