In-place changes: Reference resolution happens before outputSourceNode is injected into an outcome model, hence targetModelReference is always null.
Though this doesn't bring any problem in most cases (DynamicReference ignores this argument most of the time), the defect
shows up for classifier nodes (e.g. Tuples) that are created as part of RootMappingRule (hence are not represented as part of input-output mappings) and get resolved
by name. Without proper model reference, name of the node (e.g. NamedTuple) is not sufficient to resolve
(scope can't resolve reference's own model by id - I don't know why). With target model reference, short resolveInfo is translated into FQN
(in DynamicReference cons) and later resolution uses this fqn instead of modelId.
In-place: defect when reference points to an element somewhere deep under removed one: Tuple with method transformed to Class with the same method.
Preparing references for in-place change records invalid target (i.e. Tuple, removed node, not the original reference target), and once the reference
is resolved (as DynamicRef), name of the Tuple shows up instead of method name.
Refactor: streamlined copySrc
copySrc refactoring leftover
DeltaBuilder: respect rare case when a root is used to produce few new roots (keepSourceRoot == true) and later removed with DropRule.
Tell more about role validation failure location.
Merge branch 'master' into 3.1/artem/default