The essential contribution of this PR is the removal of some functionality in the UuidGeneratorAndResolverImpl related to resolving objects across resource sets, which should not be in the responsibility of that resolver. The new, simplified behavior only loads UUIDs from a parent resolver on creation of the child resolver or on addition of a resource to the monitored resource set.
The logic for resolving UUIDs for EObjects across resource sets was actually only necessary for retrieving corresponding elements from test view resources. However, although we did not face any problems yet, usign the UuidResolver in its precious state for that relies on some implicit assumptions, especially that resources are in an equal state as otherwise the cross-resource-set resolution of objects may fail or lead to invalid results (because the URI calculated for finding elements matched although the elements are actually different). That assumption may be broken easily without any benefits for the production code.
In addition, there were some tests that used the ability of the UuidResolver to retrieve UUIDs not only for elements from the managed resource set but also from other test resource set, but there is no essential functionality in production code that requires this resolution mechanism.
As a result of this PR, the UuidGeneratorAndResolverImpl is only able to process EObjects within its managed resource set, and it enforces that for each EObject only a single UUID is registered and vice versa. By now, it was possible to overwrite existing UUIDs for EObjects and vice versa, which is not intended behavior of unique IDs.
The essential contribution of this PR is the removal of some functionality in the
UuidGeneratorAndResolverImplrelated to resolving objects across resource sets, which should not be in the responsibility of that resolver. The new, simplified behavior only loads UUIDs from a parent resolver on creation of the child resolver or on addition of a resource to the monitored resource set.The logic for resolving UUIDs for
EObjects across resource sets was actually only necessary for retrieving corresponding elements from test view resources. However, although we did not face any problems yet, usign theUuidResolverin its precious state for that relies on some implicit assumptions, especially that resources are in an equal state as otherwise the cross-resource-set resolution of objects may fail or lead to invalid results (because the URI calculated for finding elements matched although the elements are actually different). That assumption may be broken easily without any benefits for the production code.In addition, there were some tests that used the ability of the
UuidResolverto retrieve UUIDs not only for elements from the managed resource set but also from other test resource set, but there is no essential functionality in production code that requires this resolution mechanism.As a result of this PR, the
UuidGeneratorAndResolverImplis only able to processEObjectswithin its managed resource set, and it enforces that for eachEObjectonly a single UUID is registered and vice versa. By now, it was possible to overwrite existing UUIDs forEObjectsand vice versa, which is not intended behavior of unique IDs.Closes #452.