| Load resources from revision control [message #1835821] |
Mon, 14 December 2020 05:55  |
Eclipse User |
|
|
|
Hey guys,
we are struggling with a proper integration of the compare feature with the different repository providers. We already had problems with the comparison for streams fetched from Perforce in the past and fixed these with a workaround in a custom IStoragePathProvider. This implementation checks if the stream path is a valid workspace path (which actually shouldn't be required) and if it is not, it will massage it a little bit - else EMF compare would run into some IllegalArgumentException in the synchronization model. So e.g. /starting.vdksys needed to be changed to P4/starting.vdksys.
We now hit another issue with comparisons against git streams, the problem here is slightly different. The jump from IStorage from the editor input to URI for loading the resource messes up the creation of the correct resource. It falls back to the default resource factory (xmi) and hence fails to load our models. This is because of the creation of the URI:
org.eclipse.egit.core.internal.storage.CommitBlobStorage@fa10bb54 -> "starting/starting.vdksys b567762"
The git suffix in the full path messes up the lookup of the resource factory by file extension in NotLoadingResourceSet.demandCreateResource(uri).
Now my question, what would be the best way to fix this and is there a way to fix it for _any_ repository provided IStorage?
I stumbled over this enhancement by Ed in EditUIUtil to support loading from the storage's getContents:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=434808
https://git.eclipse.org/c/emf/org.eclipse.emf.git/commit/?id=a77a5ec24411151dc1dc9754f4edde9a441fb58e
Would something similar be suitable here? Or is "another IStoragePathProvider" approach better here to make the resource factory registry find the correct resource type again? I see that sooner or later we would need more workarounds for similar issues - maybe somebody already fixed this in an elegant way.
Thanks
Janik
|
|
|
|
Powered by
FUDForum. Page generated in 0.03549 seconds
Home