|
| Re: Model merger not found [message #1752709 is a reply to message #1752581] |
Thu, 26 January 2017 12:11   |
|
Hi Monica,
We use that condition to double-check that the model provider does indeed match the model for which we're seeking an adapter, ensuring that the proper model provider is used. The fact you happen on this issue seems pretty strange to me... did you refresh the workspace files after commiting and before starting the merge? If EMF Compare finds these files once (modelArray) then it should find it twice (matchingResources). Could you tell us how to reproduce this behavior?
Laurent Goubet
Obeo
|
|
|
| Re: Model merger not found [message #1752723 is a reply to message #1752709] |
Thu, 26 January 2017 14:25 |
 Monica Coman
Messages: 13
Registered: January 2017 |
Junior Member |
|
|
Hi Laurent,
Thanks for the reply.
To answer your questions first:
1) No, we do not refresh the workspace files at any moment, should we? What I've noticed, however, is that in the mergeTreeWalk(...) method of the RecursiveModelMerger, the refreshRoots(...) method is called both before the creation of the logicalModel and before the creation of the modelMerger.
2) As for reproducing the behavior, I am not sure the exact same workflow can be achieved outside of our application so, unfortunately, I cannot give you any other details than what I've already mentioned in the use case above.
What I don't understand is why is it a must that the files found in the modelArray will also be found in the matchingResources.
As far as I could see from debugging through the code yesterday, the modelArray contains all the resources found by the logicalModel which is built from the knownResources of the variantTreeProvider (TreeWalkResourceVariantTreeProvider).
The variantTreeProvider will, of course, also consider the resources that are on the remote because the remote (THEIRS) tree contains them and they are all added to the knownResources set, therefore they will all be added to the modelArray as well:
knownResources = new LinkedHashSet<IResource>();
knownResources.addAll(baseCache.getKnownResources());
knownResources.addAll(oursCache.getKnownResources());
knownResources.addAll(theirsCache.getKnownResources());
On the other hand, matchingResources only contains files that exist in the local workspace, therefore the remote ones will never be found since they are only copied locally after the merge process has finished successfully.
Another thing that confuses me is the comment of the build(...) method in LogicalModels:
/**
* Iterate over the resources in the given set to discover and cache the logical model of each.
* <p>
* Resources that do not exist locally will be excluded from the lookup to avoid NPEs from the expression
* framework (model providers look for the resource's content type, which fails for remote resources). If
* these resources _are_ part of a larger model, it will be detected through the "other parts" of said
* model.
* </p>
* <p>
* Models provided by the {@link #ignoredModelDescriptors} will be ignored from this lookup.
* </p>
*
* @param resources
* @param remoteMappingContext
*/
If resources that do not exist locally will be excluded from the lookup, how come my new file from the remote is not excluded? Or perhaps "locally" in this context means something different?
Could you please clarify some of these concepts and tell me if there is something I misunderstood?
What I did as a solution, for now, is to remove the remote resources from the knownResources list before building the logical models:
Set<IResource> knownResources = variantTreeProvider.getKnownResources();
ArrayList<IResource> toBeRemoved = new ArrayList<>();
for (IResource iResource : knownResources) {
if (!iResource.isLocal(IResource.DEPTH_INFINITE)) {
toBeRemoved.add(iResource);
}
}
knownResources.removeAll(toBeRemoved);
logicalModels.build(knownResources, remoteMappingContext);
|
|
|
Powered by
FUDForum. Page generated in 0.03227 seconds
] 
Search
Help
Register
Login
Home
