Re: [mylyn-context-dev] MFT and EMF Client Platform

[Miles Parker <miles.parker@xxxxxxxxxxx>]

On 2013-02-05, at 1:16 AM, Sebastian Schmidt <mail@xxxxxxxxxxxxxx> wrote:
> 
> Anyways, the paths seem to be somewhat irrelevant:
> - bound to one pc
> - even bound to one "checkout": if I checkout a project, delete it,
> check it out again - from the exact same EMFStore - the paths are
> changed.

Yes, this is the downside of using non-semantic UUIDs in this way, I guess.

> 
> So I guess I'll try to come up with another structure bridge which
> inherits from EmfStructureBridge and supports this special case.

Right, that seems to be what makes the most sense. Shouldn't be *too* difficult to do..unfortunately, there is still a lot of trivial plumbing that needs to happen, but it's all pretty straightforward.

> 
> Cheers,
> 
> Sebastian
> 
> On Mon, Feb 4, 2013 at 8:37 PM, Miles Parker <miles.parker@xxxxxxxxxxx> wrote:
>> 
>> On 2013-02-04, at 11:30 AM, Carsten Reckord <reckord@xxxxxxxx> wrote:
>>> 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.
>>> 
>>> Sorry, forgot the important point: we actually do use the URI as-is for
>>> EObjects. We just handle the containing resource specially if it points to a
>>> workspace location.
>> 
>> Right -- it's been a while! So here we *do* want a file that can be located in the user workspace. Which leads the question of where the EMF Client parent references will be in the actual workspace and if not, how they are located for the context in the first place. Interesting.
>> 
>>> 
>>> 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
>>> 
>>> _______________________________________________
>>> 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
> _______________________________________________
> mylyn-context-dev mailing list
> mylyn-context-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/mylyn-context-dev