Community
Participate
Working Groups
Merging model fragments into a model is a non-trivial task. There are various issues with merging fragments into the E4 model now. This bug is used describe the problem, discuss solutions and to track the issues. Current behavior is implemented in ModelAssembler, ModelUtils and StringModelFragmentImpl. Current base: A) Element-identifiers are not unique, the same identifier can be used for multiple elements. These elements can have different types, but can also have from the same type. B) Model elements do have an unique UUID. C) Fragments are used to add new elements to specific (containment) features of a parent element. - The parent element is selected by: 1) One element-identifier, 2) A list of element-identifiers, or 3) A xpath query (introduced by Bug 437958). The type of the parent element is not defined. - A feature is selected by name, the type of a feature is not specified. - Optionally the position in a feature is specified with a 'Position in list expression'. This expression can refer to other elements in the same feature. D) Fragments can extend fragments that still need to be merged into the model. This can be the case for parent selectors as well as for the position in list selector. E) Elements can be contained by only one element. Therefore, elements must be duplicate/copied when elements are added to the model more than once. As a result, the copied elements they will have different UUIDs than the original element. The element-identifier will be the same for all elements. F) When a fragment is added with the extension point, an merge policy can be provided: always, initial, notexists. Current observed problems: 1. As element identifiers are not unique, the fragment parent selector can match to multiple elements. When specifying an element-identifier as parent, should the fragment be applied to all elements matching this identifier or only the first found? Current implementations applies to the first found element only, this can be an element for which the feature or children's type do not match. 2. Ordering algorithm is incorrect: - The order in which fragments are is important, currently the order is not correct in all cases. This can result in some elements not being merged, e.g. Bug 529924 and Bug 551634 - The current ordering algorithm assumes that element-identifiers are unique, e.g. Bug 562472 - The current ordering algorithm does not consider xpath expressions 3. The fragment policy is ignored, e.g. Bug 440030. Moreover, without a strategy to identify if an element resulted from applying a fragment it is impossible to check if the fragment was applied before. This is especially true for copied elements. 4. ModelUtils#merge uses the element identifier (if set) to check it an element is already in the feature. This can result in false positives/negatives. Resulting in elements not being added or duplicated, e.g. Bug 379216 5. It is possible to try to merge objects of incorrect types into a feature, e.g. Bug 369976 and Bug 547839 6. There is no or cryptic feedback when a fragment is merged, e.g. Bug 381916 and Bug 551851 Previous suggested Improvements: 7. Allow different merge strategies for each model fragment: Bug 526256 8. Improve the UI to prevent mistakes in selection features: Bug 478319. In conclusion, the main issues are related to matching elements (i.e. what identifies an element), weak typing, the order in which fragments need to be applied, and traceability if an fragment has been applied before. Note that fragment dependencies can result in (pseudo) cycles between to be added elements. I think that these issues are all kind of related, and might need a general redesign of the merge strategy. (However I don't think I have sufficient time available to tackle this issue.)
May I add another issue? Currently there is only a strategy for merging at startup but no strategy for removal or update. This currently leads to strange behavior (e.g. when a bundle is updated the fragment stays in place and now maybe outdated or invalid classes/objects are referenced. I'm not familiar enough to judge if its possible but maybe someone else could give an idea if this is possible: Its would be good if the model is not actually merged into one big "thing" but a dynamic structure is used that combines elements on the fly, then some of the problems would automatically disappear (e.g. ordering would only be an intermediate problem). Simple example: Instead of adding all elements to a global list, the global list is just a view that delegates to all child fragments (think about it as a UNION SELECT in SQL).
