Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mylyn-context-dev] MFT and EMF Client Platform 
On 04.02.2013 20:14, Miles Parker wrote:
> 
> Yeah, though thinking about it, I don't think it is the kind of thing that MFT should be trying to 'fix', we should just be making sure that we handle the URIs in exactly the same way that any other resource consumer would. If other items use file references, they're going to be absolute as well. And here we have a case where the location is actually in a user configuration directory, which will of course have a different relative path from anything in the workspace. I don't know if EMF client creates local stores that are representing some local connection or what...

Yes, thinking about it, that could quickly become a slippery slope...

> Parenthetically, the platform URI scheme doesn't actually seem to support a shared "User Area" location:
> 
> http://lmap.blogspot.ca/2008/03/platform-scheme-uri.html
> 
> But it seems that it would make sense for EMF Client to adopt some sort of scheme where those local user URIs were stored in a more generic way. Or perhaps they do, but we're not treating them correctly. Looking at the code for EMFStructureBridge (L 189), I'm not sure why we're not just using the URI as is. 

In L189, and then further in getFile (L208), we are trying to resolve the
parent container when the emf hierarchy ends. This is needed in order for
model files and their folders to receive parent interest - and hence become
visible - when an EMF object is manipulated.

getFile could be done a bit prettier, but overall that looks pretty correct
to me...

> Sebastien, what do other internal reference URIs look like?
> 
> On 2013-02-04, at 10:59 AM, Carsten Reckord <reckord@xxxxxxxx> wrote:
> 
>> On 04.02.2013 19:46, Miles Parker wrote:
>>>
>>> Hi Sebastien,
>>>
>>> MFT simply uses whatever URI your model uses. So for workspace resources, for example, it'll use:  StructureHandle="platform:/resource/org.eclipse.mylyn.modeling.tests.ecorediagram/model/library.ecore#//Library" which would of course work fine when sharing across workspaces with the same project structure. So at first glance it looks to me like something to do with the way that EMF Client is storing those references.
>>
>> Indeed. I'm not familiar with EMF Store, but I wonder if they don't have
>> their own URI scheme and resolution strategy that would hide the actual file
>> location similar to the platform:/resource/ URIs for workspace resources.
>>
>> That said, we could probably handle file URIs a bit better by making them
>> relative to the workspace location. I'll raise a bugzilla to discuss that.
>> _______________________________________________
>> mylyn-context-dev mailing list
>> mylyn-context-dev@xxxxxxxxxxx
>> http://dev.eclipse.org/mailman/listinfo/mylyn-context-dev
> 
> _______________________________________________
> mylyn-context-dev mailing list
> mylyn-context-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/mylyn-context-dev
> 

-- 
Carsten Reckord
  t  +49 (0)561 5743277-33
  f  +49 (0)561 5743277-8833
  e  reckord@xxxxxxxx

Yatta Solutions GmbH
  Sitz der Gesellschaft: Kassel
  Amtsgericht Kassel, HRB 14720
  USt-IdNr DE263191529

Geschäftsführung:
  Johannes Jacop,
  Dr. Christian Schneider

Adresse:
  Ludwig-Erhard-Straße 12
  34131 Kassel

Kontakt:
  t  +49 (0)561 5743277-0
  f  +49 (0)561 5743277-88
  e  info@xxxxxxxx

Bankverbindung:
  Kasseler Bank eG
  BLZ 520 900 00
  Kto-Nr 158 305

Back to the top