Community
Participate
Working Groups
Currently references to external EObjects are only tracked, if the actual EObjectDescription was taken from the global scope. The ImportedNamesAdapter which wraps global scopes during the linking phase does this. However in situations, where you look up elements from external EObjects which have been loaded in the local scope provider, the reference is not tracked. A typical example is a feature on a class, which is referenced by a feature call. Example: "foo".length() 'length()' in this case could be a reference to java.lang.String.length(). The scope containing that element, would typically be created in the local scope, by using the type of the target expression (i.e. java.lang.Sting in this case). As the global scope was never asked for 'java.lang.String.length()' the resource wouldn't be treated as affected if the methods signature changes. A possible solution would be to use aliases locally, so in case the scope is asked for an element of name 'length' the local scope actually calls its parent for the qualified name of the element 'java.lang.String.length()'. Another solution could be to wrap any local scopes, and track during linking whether the returned IEObjectDescription is contained in a different resource and if so, register the IEObjectDescription.getQualifiedName.
Wouldn't it be the responsibility of IResourceDescription.getReferenceDescriptions() to export an IReferenceDescription if the reference should be tracked? By "tracked", do you mean "made available in IResourceDescription.getImportedNames()"?
I meant add the qualified names to the list of names in IResourceDescriptin.getImportedNames(), which is the information on which IResourceDescription.Manager.isAffected(Delta, IResourceDescription) is based by default.
(In reply to comment #2) > I meant add the qualified names to the list of names in > IResourceDescriptin.getImportedNames(), which is the information on which > IResourceDescription.Manager.isAffected(Delta, IResourceDescription) is based > by default. #isAffected takes the actually established cross references into account, too. However, it will still return false as soon as a new method is introduced in the referenced type that overloads / overrides the previously referenced method, e.g. 123.value where 123's type is MySpecialNumber type and I introduce getValue in MySpecialNumberType. I don't think it's the right way to add MySpecialNumberType#value, MySpecialNumberType#getValue, MyNumberType#value ... to the list of imported names. It should be possible to add synthetic references to the list of reference descriptions that point to the resources of the actually referenced types.
closing this as WORKSFORME, since this is considered a language specific problem. We can't solve every language's problem in a generic way.
