Community
Participate
Working Groups
Created attachment 234007 [details] git repository that can be used to reproduce the bug Eclipse Modeling Tools Version: Kepler Release Build id: 20130614-0229 EMF Compare GMF Integration 2.1.0.201306101322 org.eclipse.emf.compare.diagram.gmf.feature.group Eclipse Modeling Project EMF Compare Papyrus Integration 2.1.0.201306101322 org.eclipse.emf.compare.diagram.papyrus.feature.group Eclipse Modeling Project EMF Compare UML2 Integration 2.1.0.201306101322 org.eclipse.emf.compare.uml2.feature.group Eclipse Modeling Project Steps to reproduce: 1/ Create a new git repository in the current Workingspace (mygitrepos) 2/ Create a new project with the same name in the Workingspace (mygitrepos) 3/ Create a papyrus model into the new project (model.di/.notation/uml), select (randomly) activity diagram 4/ Commit the model and .project file into the repository 5/ Open the model, and add an Initialnode element into it. Save. This is how things now look from the command line: [kgad@Klaass-MacBook-Air ~/Workspaces/semanticmatching/mygitrepos]$ git diff model.uml diff --git a/model.uml b/model.uml index f7eb987..9536bfd 100644 --- a/model.uml +++ b/model.uml @@ -1,4 +1,6 @@ <?xml version="1.0" encoding="UTF-8"?> <uml:Model xmi:version="20110701" xmlns:xmi="http://www.omg.org/spec/XMI/20110701" xmlns:uml="http://www.eclipse.org/uml2/4.0.0/UML" xmi:id="_-Ng7QPp-EeKoM4Q - <packagedElement xmi:type="uml:Activity" xmi:id="_-NiJYPp-EeKoM4QATFRWyA" name="Activity1"/> + <packagedElement xmi:type="uml:Activity" xmi:id="_-NiJYPp-EeKoM4QATFRWyA" name="Activity1" node="_Mw2B0Pp_EeKoM4QATFRWyA"> + <node xmi:type="uml:InitialNode" xmi:id="_Mw2B0Pp_EeKoM4QATFRWyA" name="InitialNode1"/> + </packagedElement> </uml:Model> You can find the zipped version of the repository/project in attach. 6/ In eclipse, right-click on the UML-model, and select "Compare with" -> Head revision. The following exception occurs: !ENTRY org.eclipse.core.jobs 4 2 2013-08-01 09:51:49.864 !MESSAGE An internal error occurred during: "Compute Model Differences". !STACK 0 java.lang.IllegalArgumentException: Path must include project and resource name: /model.uml at org.eclipse.core.runtime.Assert.isLegal(Assert.java:63) at org.eclipse.core.internal.resources.Workspace.newResource(Workspace.java:2170) at org.eclipse.core.internal.resources.Container.getFile(Container.java:208) at org.eclipse.emf.compare.ide.utils.ResourceUtil.createURIFor(ResourceUtil.java:227) at org.eclipse.emf.compare.ide.internal.utils.NotLoadingResourceSet.loadResource(NotLoadingResourceSet.java:121) at org.eclipse.emf.compare.ide.internal.utils.NotLoadingResourceSet.create(NotLoadingResourceSet.java:72) at org.eclipse.emf.compare.ide.ui.internal.logical.EMFSynchronizationModel.createScope(EMFSynchronizationModel.java:349) at org.eclipse.emf.compare.ide.ui.internal.logical.EMFSynchronizationModel.createMinimizedScope(EMFSynchronizationModel.java:333) at org.eclipse.emf.compare.ide.ui.internal.structuremergeviewer.EMFCompareStructureMergeViewer.compareInputChanged(EMFCompareStructureMergeViewer.jav\ a:344) at org.eclipse.emf.compare.ide.ui.internal.structuremergeviewer.EMFCompareStructureMergeViewer$1.run(EMFCompareStructureMergeViewer.java:260) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
The issue here is that EMF Compare does not support models in a project that is also the repository itself (though you can still fall back to textual compare in these cases). You can workaround this issue by creating a subfolder within the repository to be the project holding your models. I.e. : create a new project in eclipse, create the model in it, then place this project in a git repository. Your model path should end up being "<repository>/<project>/<model>" instead of "<repository>/<model>". The issue lies in the very same place I hinted at on bug 397955 comment 4. Basically, the path is wrong (we do not have the project in it), but we do not have an easy work around for that. We'll see if we can fix this before Luna, but we have other priorities for now.
Is there any work on this regard? It's very annoying that one cannot compare a model contained in a working copy with its correlated model in an SVN repository. As I remember correctly this worked in Indigo already but since Kepler not anymore.
Jan, Comparing with SVN worked with EMF Compare 1.3, but not since EMF Compare 2.0. There are no plans to work on this before we have completed the EGit support, but we will consider contributions in that direction. Please see bug 397955 comment 4 if you are interested in trying to come with a fix for SVN comparisons. Otherwise, if you are interested by this support but cannot (or don't wish to) contribute time on it, you can also contact Obeo to fund the development of this feature.
Laurent, there is already a patch proposal from last year at the bug you mentioned. Is the patch not working or why is it not applied?
That patch was not acceptable as is since it only hid the issue without really solving it, and that new developments made it fail anyway (at least with the testing I had made at the time)... but I never answered on the bug, which is an issue on my side.
Created attachment 244913 [details] Plugin providing an adapter for ResourceElement to IFileRevision This plugin just registers an adapter factory and a SVNFileRevision implementation for adapting ResourceElement (which comes from the *team.svn* plugins) to IFileRevision (used in the *team.core* plugins).
Created attachment 244914 [details] Adapters are accessed by loading the contributing plugins Just a small correction in the PlatformElementUtil class which now loads an adapter via the adapter manager to load the contributing plugin respectively.
A submitted two attachments. The first is a plugin which registers an adapter factory to adapt the ResourceElement, deliverd by org.eclipse.team.svn.ui, to the IFileRevision, delivered by org.eclipse.team.svn.core. It seems that the team core stuff doesn't have a precise API, thus, no further assumptions can be made about what is returned by contributors. That's why I thought providing a plugin (as a lightweight extension) contributing an adapter factory to adapt both is a proper solution. At least it works for me ;) I know that such an adapter should have been provided by the Subversive guys and not by the EMFCompare guys. But maybe you can forward the stuff to them.
Jan, I tested the plugin and it works for me when comparing a local file resource with a remote revision. Hoewever, when I select team / show history and select two remote revisions with 'compare with each other' the error still exists. This can be fixed by removing the localResource != null check in ResourceElementIFileRevisionAdapterFactory.
Andreas, thanks for the hint!
Created attachment 244923 [details] Plugin providing an adapter for ResourceElement to IFileRevision Updated plugin providing an adapter for ResourceElement to IFileRevision with regard to the hint of Andreas Mülder.
Jan, Andreas, A new plugin seems like the best solution for SVN, and we'll be able to contribute it through the "integration" category of our update site. What I've seen so far of the code seems sensitive enough, but could you provide it through gerrit instead of an attachment on bugzilla? See also http://wiki.eclipse.org/EMF_Compare/Gerrit for info on how to contribute to Gerrit. I've seen a few things that should be changed though, so before you push it on gerrit : on the first patch * SVNFileRevision: ** constructor assert repositoryResource != null; assert resourceElement != null; this.repositoryResource = repositoryResource; this.resourceElement = resourceElement; can be changed to this.repositoryResource = Preconditions.checkNotNull(repositoryResource); this.resourceElement = Preconditions.checkNotNull(resourceElement); ** "printStackTrace" should be changed to logging the throwable ** "isPropertyMissing" should probably return "false" since "withAllProperties" does nothing? * ResourceElementIFileRevisionAdapterFactory ** getAdapter if(adapterType != null && adaptableObject != null && adapterType.equals(IFileRevision.class) && adaptableObject instanceof ResourceElement) can be changed to if (IFileRevision.class.equals(adapterType) && adapatableObject instanceof ResourceElement) Please add your copyright on both files too. We'll see on gerrit if there's anything else that needs changing :).
I don't know how to use Gerrit. As expected I don't have the rights to push. So I add the plugin as an attachment here again, incorporated all your suggestions. When you integrate it, don't forget the earlier patch of the PlatformElementUtil otherwise the adapter factory won't be loaded.
Created attachment 244927 [details] Plugin providing an adapter for ResourceElement to IFileRevision
Hi Jan, You have the right to push to gerrit since you have signed the CLA. However, your user.name and user.mail git configuration must correspond to your eclipse account (as shown on http://wiki.eclipse.org/EMF_Compare/Gerrit#Update_repository_information) and you need to push to "refs/for/master" instead of the "normal" "refs/heads/master" (as shown on http://wiki.eclipse.org/EMF_Compare/Gerrit#Adding_a_new_remote). Gerrit is much easier on us for the reviews, and it also simplifies the integration of code to the actual repository. In the meantime, I'll look at these patch the old way, but please consider setting up your gerrit account properly for subsequent patches (and patches to other gerrit-enabled projects). This also makes the contribution process easier for you once it's in place, so it should be pretty much win-win.
Laurent, thanks to your additional explanation on how to use Gerrit I finally could push the modifications for review: https://git.eclipse.org/r/#/c/29727/ thanks!
(In reply to Jan Reimann from comment #16) > Laurent, thanks to your additional explanation on how to use Gerrit I > finally could push the modifications for review: > https://git.eclipse.org/r/#/c/29727/ > Thanks for taking the time to tackle this. I've updated the review in order to make the necessary cosmetic changes to fit it into EMF Compare (mainly changed the namespace from "team.svn.ui" to "emf.compare.subversive"). Could you both test this new patch set and check that it works for you? All that's left is for me to add this to the build and update site, but I'd like your feedback in the meantime :). (Note that you can simply cherry-pick the change in your clone of EMF Compare : on the gerrit UI, in the "download" line of the table, tick "cherry-pick", copy the line just below, and paste it in your console)
Your modifications work. Furthermore, I removed the @override annotations for methods implementing interface methods (because if compliance level 1.5). But, I get "[remote rejected] HEAD -> refs/for/master (missing Change-Id in commit message)" although I added a Change-Id. So I added comments in a review to remove the annotations. Maybe you can do it.
Hi Jan, I believe I have already removed the extraneous @override, but I'll double check that. Thanks for confirming that this latest patch works. ALos, the "(missing Change-Id in commit message)" is strange, if you've chery-picked the latest patch from https://git.eclipse.org/r/#/c/29727/(see comment 17), you should already have the following in the commit message footer : Bug: 414180 Bug: 397955 Change-Id: Ie0fe4275b0290df9a5aaebb2c5430e0e69d7c210 Signed-off-by: Jan Reimann <janreimone@gmail.com> Signed-off-by: Laurent Goubet <laurent.goubet@obeo.fr> Although, when pusing to gerrit, all of the commits you have that differ from head will be pushed as separate patchs. If you've cherry-picked this change on top of another commit that's not in the remote code base, gerrit will try to push that one first, as a dependency of the second.
Laurent, great. Will this fix be available in any nighty update site?
The patch has been merged on master, along with the patch that adds it to the update site (https://git.eclipse.org/r/#/c/29815/). This will be included in the next nightly of EMF Compare. I'll also backport both of these patchs to the 3.0 maintenance branch, so the subversive support will be present in Luna SR1.
Laurent, if I use http://download.eclipse.org/modeling/emf/compare/updates/nightly/latest for installation I only see GMF, Papyrus and UML2 integration features in the EMF Compare Tools Integration category. Maybe I should wait for the next successful build?
Jan, I've just rolled a new nightly with these changes, so you should be able to install it now.
Update site works. Finally, I can compare my ecore files against the SVN repository again. Thanks Laurent. Another question: is there any information about how to proceed to graphically compare GMF-based diagrams? I installed the GMF integration plugin as well, and my ecorediag diagrams are only compared textually.
Please use the forum (or another bugzilla entry) for unrelated questions (or bugs). That being said, Luna shipped with ecore tools 2, powered by Sirius, so we've disabled the ecoretools integration feature until we can test and ensure we work with it. The GMF integration feature you've installed only works with pure GMF diagrams. However, the "ecoretools integration" feature only consists of a single plugin.xml entry. You can test manually if you wish : open the preferences and go to General > Content Types, browse to the "EMF Compare" content-type and add "*.ecorediag" in there. That will tell EMF Compare to consider the ecorediag files as being models and comparable as such. I don't know if the ecoretools 2 support is functional though, since it is untested.
Backported as on the 3.0 maintenance branch as https://git.eclipse.org/c/emfcompare/org.eclipse.emf.compare.git/commit/?h=3.0&id=fe5f4a6f3d9685d24ff3e60b40c3920f645f200b . This will be present in both Mars M1 and Luna SR1.
