Community
Participate
Working Groups
M4: A reference such as <eStructuralFeatures xsi:type="ecore:EReference" name="namespace" eType="ecore:EClass ../../org.eclipse.ocl.examples.pivot/model/Pivot.ecore#//Namespace"/> is reported as a difference when comparing a local file to its GIT head revision. The textual comparison shows no diofference.
Still fails in 2.1. This needed a bit of a tweak to take git specificities into account when resolving relative paths; namely, git uris are deresolved into the workspace as platform:/resource/<repository name>/<workspace relative path> ... which cannot work. This fix will be available in the next integration build.
(In reply to comment #1) > This needed a bit of a tweak to take git specificities into account This sounds like a tweak to (partially) hide a bug. If platform:/resource and platform:/plugin are neutral normalizing path locations everything should be regular.
Ed, This bug reminded me of how EMF manages to find files with relative URI "../../plugins/..." when the "source" file is _not_ located under Eclipse (an imported project from git for example). If I have a project P1 with a model M.ecore, located on disk in "g:/git/repo/P1", my workspace is located at "g:/dev/eclipse/workspace", then M.ecore should never reference Ecore.ecore as "../plugins/org.eclipse.emf.ecore/model/Ecore.ecore". And yet it sometimes does, and that does not fail. I never really undersood all of the magic that's involved when normalizing URIs : how can a borken relative URI be resolved to the good location? Why didn't we fix the broken path instead of making it point to the real location? Whatever the case, relative URIs with models in git repositories seem to often normalize to "platform:/resource/<repo>/<project>/path/to/model.ecore". I was not in the mood to debug too far in the URI magic to try and understand just "how" such a path could be properly resolved. These might even be because of manipulations EMF Compare does when resolving the logical model. For now I simply removed the spurious "<repo>" segment. I know from experience (and other bugs) that this probably won't be sufficient for some corner cases... We'll see as they are detected and reported.
(In reply to comment #3) > Whatever the case, relative URIs with models in git repositories seem to > often normalize to > "platform:/resource/<repo>/<project>/path/to/model.ecore". I agree completely that these need to be fixed. They are absolutely wrong. I suspect that they derive from some naive code somewhere that endeavours to interchange file: and platform: paths without determining the true normalisation. You may recall that I explained this in https://bugs.eclipse.org/bugs/show_bug.cgi?id=360926#c7 and complained about inaccurate Acceleo normalisation. It may be that some of the bad URIs you are trying to handle are caused by the erroneous Acceleo and related code. The MDT/OCL ProjectMap allows accurate normalisation. Recent changes to the EMF EcorePlugin.getEPackageNsURIToGenModelLocationMap provide much of the same functionality; ProjectMap goes a bit further in allowing schizophrenia to be suppressed unless explicitly required. I fear that the longer you put off getting to grips with accurate URI normalisation, the more problems the inaccurate URI normalizers will cause. In so far as there is a legacy bad practice problem and EMF Compare is at the bleeding edge of the problem, perhaps EMF Compare needs preference options to enable repair/diagnosis of particular bad practices with a view to tracing the bad URIs back to the generator. I leave it for you to REOPEN this bug.
Ed, Unfortunately in the case of EMF Compare, I do not think that there is an "accurate" way to handle our URIs : for a simple example, right-click one of your ecore or genmodel files (in a Git repo), use Team > Show in history. In the history view, select a commit and, in the right pane, locate the "model" file (ecore, genmodel, whatever). Right-click it > open in Editor. You should see an emf editor that simply failed to load the model (file not found exception). The goal of EMF Compare is precisely to handle such models, load it as EMF model, and resolve their relative URIs... as remote revisions : ecore.genmodel references "ecore.ecore". We can't let EMF load the "ecore.ecore" file it knows : we need the "ecore.ecore" reference to be a remote revision corresponding to the ecore.gemodel file currently being loaded. This is not the problem we tried to tackle with Acceleo. If the code we have to try and find these remote revisions can be simplified in any way, I'll be more than happy to give it a try, especially since EMF Compare 2 is still young and uncluttered enough that we can easily try other approaches... But these are not the only problems we have, and we can't spend too long experimenting with this while only scratching the surface. We need to be able to handle EGit, CVS, Subversive, Subversion, Clearcase... and how they all see "URIs" in their own way (and the way they implement the Team APIs, but that's another matter). As I mentionned, This issue with EGit might be us using a too eager "createPlatformResourceURI()", but it also has a good chance to be because of Git's URIs : they are relative to the repository root, not relative to Eclipse workspace, which could explain why EMF does not manage to open a model "as seen by EGit" in the history view... But even if EMF "could" handle these "Git" URIs... how would it resolve the relative ones? towards the workspace? Since that's a file from the history, the relative path points to a something that was true in the past (at the time of that particular revision), and that relative location might be void in the workspace. Should EMF integrate with EGit, or should EGit provide an integration with EMF (namely, an URIConverter aware of IFileRevisions)? A generic URIConverter aware of file revisions would have its place in a "Team" integration with EMF, or an EMF integration with Team... not specifically with EGit : Subversive will have the same issue. I've diverged a little, but that's really the real theme of this bug : "Team" and "EMF" are not aware of each other. EMF Compare tries to close the gap, but that's a heavier endeavour than just providing comparison features... For now we do what we can with URIConverters and the model providers API of Team. If you think that there is still something we could do better without spending weeks trying to pinpoint all use cases "Team" offers (or simply general advices if there's something we do plain wrong :)), please develop.
(In reply to comment #5) > Right-click it > open in Editor. > > You should see an emf editor that simply failed to load the model (file not > found exception). I chose the simplest self-contained *.ecore I could. You're right it just doesn't work and since this surely doesn't use EMF Compare there is a bug in GIT's activation context for an EMF editor (and no doubt for a Compare editor). (I leave it for you to raise the GIT Bugzilla.) For your own accelerated development purposes you may want to workaround/fix the bug, but the GIT Bug should be fixed for Kepler so that your code can be clean in Kepler. [This is perhaps an example of tracking down the true URI offenders so that their offences don't pollute all modeling projects.]
This is something we've observed since we started using EGit. Please see bug 354801 for reference.
Closing this since EMF Compare does not present this particular issue anymore. Will need to be fixed in EGit for a more permanent solution.
