Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Compare » Model merger not found
Model merger not found [message #1752581] Wed, 25 January 2017 10:13 Go to next message
Monica Coman is currently offline Monica ComanFriend
Messages: 13
Registered: January 2017
Junior Member
Hi!

I am using EMF Compare to handle model merging in my own EMF-based application and I have encountered a problem when merging.

The use case I've been looking at is the following:
1. A model has one local, non-conflicting change and the user tries to merge another non-conflicting change from the remote. The models we use are split into multiple files and the changes in this use case represent new files added to the model. (both the local and the remote add new files)
2. Before starting the merge we commit all local changes and start the merge process (using the JGit MergeCommand for each commit coming from the remote)

The problem appears during the merge process. In the mergeTreeWalk(...) method of the RecursiveModelMerger class, the modelMerger returned by the method LogicalModels.findAdapter(...) is null for all iterations of resources belonging to the model. This happens because of the following condition in the findAdapter method:
if (matchingResources.length == modelArray.length)

It seems like the new file created on the remote is not found by the IModelProviderDescriptor, therefore, the size of the matchingResources array will always be smaller than the size of the modelArray.

I was wondering why is this condition required and how can this case be handled?
Re: Model merger not found [message #1752709 is a reply to message #1752581] Thu, 26 January 2017 12:11 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1843
Registered: July 2009
Senior Member
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 Go to previous message
Monica Coman is currently offline Monica ComanFriend
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);



Previous Topic:Merging file deletions in multi-file model
Next Topic:Behaviour of "Previous Difference" and "Next Difference" buttons for tree expand
Goto Forum:
  


Current Time: Fri Jan 19 23:31:40 GMT 2018

Powered by FUDForum. Page generated in 0.01732 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software