Make DSLs use metamodels instead of VitruvDomains

[HeikoKlare]

This PR makes the DSLs (Reactions, Mappings, Commonalities) independent from VitruvDomains.

• It makes the Reactions refer to metamodels instead of VitruvDomains and generates appropriate code for the ChangePropagationSpecifications that have already been adapted to use metamodels wrapping namespace URIs rather than VitruvDomains in Separate change propagation from VirtualModel #501.
• It makes the Commonalities explicitly refer used metamodels instead of implicitly accessing all available VitruvDomains.

It also updates the features and the updatesite categories to separate the change part (with specification, propagation and dsls) and the V-SUM part (views, vsum, domains, applications) of the framework.

[JanWittler]

Why do we use EPackage is multiple locations instead of the MetamodelDescriptor?

Besides that looks fine to me. Explicitly importing metamodels for the Commonalities is a good scoping improvement 👍🏼 .

[HeikoKlare]

Thanks for the feedback and good question. I also thought about using some metamodel concept instead of EPackage, but at least the MetamodelDescriptor only wraps namespace URIs. We would have to extend it to also represent the EPackage(s) of the metamode,l but in the current use cases we only have the namespace URIs at hand such that a MetamodelDecriptor then may or may not provide the EPackage for the described metamodel, which is rather suboptimal behavior. What do you think?

[JanWittler]

I see. The optimal solution from my perspective was a computed accessor for the EPackages computed from the URIs but I didn't find a matching constructor for that.
If the EPackage cannot be uniquely identified based on the URI, I think it is fine to leave it in its current state. In #501 the descriptor class was introduced as the URI itself had no semantic meaning. Here, the EPackage already has one. I was just curious why the MetamodelDescriptor was not reused but your explanation makes perfectly sense.

[HeikoKlare]

A URI can be resolved to an EPackage if it is registered in some registry, usually the global EPackage.Registry. This registry must, however, not necessarily be initialized (or misses some URIs which have just been defined) but still the URIs define valid namespace URIs of metamodels.

We can either

• leave it as it is, or
• provide an EPackage resolver in the MetamodelDescriptor, which tries to resolve the EPackage from the registry but may fail.

In the latter case, we could also add a MetamodelDescriptor constructor accepting an EPackage, which ensures that the EPackage is properly registered.

[JanWittler]

This registry must, however, not necessarily be initialized (or misses some URIs which have just been defined) but still the URIs define valid namespace URIs of metamodels.

If it is a valid scenario that the registry misses some URIs we need for our DSLs, I would stay with the EPackage implementation. Otherwise we might have edge cases where the packages cannot be resolved and we run into errors that are just because we wanted to make the code look nicer but are semantically not needed.

[HeikoKlare]

Alright, I agree. So this PR is ready to merge, isn't it?