Community
Participate
Working Groups
As of 27.05.2010 my initial contribution of GenericMatchScope was changed so that resolveAll(ResourceSet) now - as a side effect - adds all resolved resources to the search scope (resourcesInScope.add(eObject.eResource())). The history says "fixing a regression on content and resourceMatch with fragmented resources introduced with the new match scoping API + providing test cases to detect such a regression in the future." I am not sure, which regression was addressed here (the history does not give any hint), nevertheless adding the respective statement is not a valid fix, as it corrupts the scoping mechanism. I.e. because of this side-effect, the search scope always contains all resolved resources, even if the scope is initialized with a single resource only.
In fact, the test cases succeed without the statement, so I propose to simply remove it again.
Alexander, I am currently trying to go through all of our bugs to see which are still reproducible; and am wondering : how did you notice a regression on this, and do you think it would be possible to create a sensible test case to avoid your scenario? (I am struggling to try and find the "test case" that the commit message talks about... I wonder if it really has been comitted.)
Ok, found the test case ... and it really fails when we remove the "resourcesInScope.add(eObject.eResource());" call. Which use case is failing in your scenario?
(In reply to comment #3) > Ok, found the test case ... and it really fails when we remove the > "resourcesInScope.add(eObject.eResource());" call. Which use case is failing in > your scenario? Laurent, as stated in my first comment, the use case is scoping the comparison to a set of resources. My concrete use case is a comparison of uml fragment resources. With the given statement, the scoping mechanism I have contributed does not work, because all resources are implicitly added to the scope.
Alexander, I haven't looked at that side of the code for a while, I need to check both the use case and the reason why we need to add all resources to the scope in order for the test case to pass. Was the test case badly written?
OK ... the test case is good; but its fix isn't. The issue here is that the test case does not provide any scope to the matching engine : we thus expect that _all_ resources are in the scope. However the "GenericMatchScope" that we use by default in such cases did not add any resource in the scope, thus the "quick fix" that is the "resourcesInScope.add(...)". We need to implement a "DefaultMatchScope" that will be in charge of resolving all resources and add them to the scope, without altering the GenericMatchEngine for that. We also need a test case that ensures no resources gets added to the resource set by the GenericMatchScope in order to prevent the regression you have on your scenario.
The match engine now uses "DefaultMatchScope" when no scope is provided within its options. This "default" scope adds all resolved resources to its scope. "GenericMatchScope" no longer adds all resolved resources to its scope, and it is no longer used by default : it is left as a base scope to be extended by clients. This has been comitted on master. Alexander, can you confirm that these changes fix your issues?
I'll assume the fix is good :).
