mylyn-context-dev http://dev.eclipse.org/mhonarc/lists/mylyn-context-dev/maillist.html mylyn-context-dev en-us Fri, 03 May 2013 18:07:43 GMT Fri, 03 May 2013 18:07:43 GMT http://blogs.law.harvard.edu/tech/rss MHonArc RSS 2.0 RCFile webmaster@eclipse.org (Webmaster) webmaster@eclipse.org (Webmaster) mylyn-context-dev http://www.eclipse.org/eclipse.org-common/themes/Phoenix/images/eclipse_home_header.jpg http://dev.eclipse.org/mhonarc/lists/mylyn-context-dev/maillist.html [mylyn-context-dev] Project meta data is out of date for mylyn.context http://dev.eclipse.org/mhonarc/lists/mylyn-context-dev/msg00065.html Shawn, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * Project home page (projecturl = http://www.eclipse.org/mylyn/context/) ... Shawn, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * Project home page (projecturl = http://www.eclipse.org/mylyn/context/) is not using an Eclipse theme. You should think about updating to the Nova theme(http://wiki.eclipse.org/Nova) ]]> Fri, 05 Apr 2013 04:00:13 GMT http://dev.eclipse.org/mhonarc/lists/mylyn-context-dev/msg00065.html emo@xxxxxxx (portal on behalf of emo) [mylyn-context-dev] Mylyn M4 BoF **Rescheduled** for Wednesday 8:00 pm http://dev.eclipse.org/mhonarc/lists/mylyn-context-dev/msg00064.html
Please note that we've rescheduled the EclipseCon Mylyn BoF for Wednesday, as a lot of the discussion will be informed by Mik's talk Wednesday morning. 

A tentative agenda is posted at the wiki page below.

http://wiki.eclipse.org/Mylyn_Meetings/EclipseCon2013BoF

I've also a list of Mylyn related talks to the page. (Please let me know if I've missed yours!) 

cheers,

Miles

On Wed, Mar 13, 2013 at 5:55 PM, Miles Parker <miles.parker@xxxxxxxxxxx> wrote:

Mylynistas,

We've scheduled a Mylyn BoF session / GeekFest at EclipseCon on Tuesday at 8:00 pm:

http://www.eclipsecon.org/2013/mylyn-bof

While we've suggested a general focus for the BoF, it's certainly not set in stone.

If you have something you'd like to make sure gets covered, you might let Benny, Sebastien or me know beforehand so we can set aside time. (We are not planning to have a projector / demos -- if this is something you _really_ want, let us know asap.)

Looking forward to it!

cheers,

Miles

______________________________
Miles T. Parker
Tasktop
http://tasktop.com
Project Lead: Mylyn MFT and AMP
Committer: Mylyn Reviews, R4E, Virgo
http://milesparker.blogspot.com



]]> Mon, 25 Mar 2013 19:16:08 GMT http://dev.eclipse.org/mhonarc/lists/mylyn-context-dev/msg00064.html miles.parker@xxxxxxx (Miles Parker) [mylyn-context-dev] Mylyn EclipseCon BoF Tuesday 8:00 pm http://dev.eclipse.org/mhonarc/lists/mylyn-context-dev/msg00063.html Mylynistas, We've scheduled a Mylyn BoF session / GeekFest at EclipseCon on Tuesday at 8:00 pm: http://www.eclipsecon.org/2013/mylyn-bof While we've suggested a general focus for the BoF, it's certainly not set in stone. If you have something you'd like t... Mylynistas, We've scheduled a Mylyn BoF session / GeekFest at EclipseCon on Tuesday at 8:00 pm: http://www.eclipsecon.org/2013/mylyn-bof While we've suggested a general focus for the BoF, it's certainly not set in stone. If you have something you'd like to make sure gets covered, you might let Benny, Sebastien or me know beforehand so we can set aside time. (We are not planning to have a projector / demos -- if this is something you _really_ want, let us know asap.) Looking forward to it! cheers, Miles ______________________________ Miles T. Parker Tasktop http://tasktop.com Project Lead: Mylyn MFT and AMP Committer: Mylyn Reviews, R4E, Virgo http://milesparker.blogspot.com ]]> Wed, 13 Mar 2013 21:54:54 GMT http://dev.eclipse.org/mhonarc/lists/mylyn-context-dev/msg00063.html miles.parker@xxxxxxx (Miles Parker) Re: [mylyn-context-dev] MFT and EMF Client Platform http://dev.eclipse.org/mhonarc/lists/mylyn-context-dev/msg00062.html Sebastien, Great! I've added a section for other implementations. See: http://wiki.eclipse.org/Mylyn/Context/Modeling_Bridge#MFT_Implementations If you have ideas for improving extensibility for future users, please open a bug or send a note to this list. cheers, Miles On 2013-02-26, at 2:15 PM, Sebastian Schmidt <mail@xxxxxxxxxxxxxx> wrote: > Hi, > > On Tue, Feb 5, 2013 at 7:10 PM, Miles Parker <miles.parker@xxxxxxxxxxx> wrote: >>> 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. > > Ok, I created a structure bridge for EMFStore and an UI structure > bridge for EMF Client Platform (ECP) editors. In case someone needs > something similar, they're available on github: > https://github.com/sschmidt/org.eclipse.mylyn.mft.emfstore > I'm essentially overwriting the methods which convert between EObject > <-> handleIdentifier and use the EMFStore ID instead of the object > URI. > > Cheers, > > Sebastian > _______________________________________________ > mylyn-context-dev mailing list > mylyn-context-dev@xxxxxxxxxxx > http://dev.eclipse.org/mailman/listinfo/mylyn-context-dev ]]> Tue, 26 Feb 2013 23:26:14 GMT http://dev.eclipse.org/mhonarc/lists/mylyn-context-dev/msg00062.html miles.parker@xxxxxxx (Miles Parker) Re: [mylyn-context-dev] MFT and EMF Client Platform http://dev.eclipse.org/mhonarc/lists/mylyn-context-dev/msg00061.html Ok, I created a structure bridge for EMFStore and an UI structure bridge for EMF Client Platform (ECP) editors. In case someone needs something similar, they're available on github: https://github.com/sschmidt/org.eclipse.mylyn.mft.emfstore I'm essentiall... Hi, On Tue, Feb 5, 2013 at 7:10 PM, Miles Parker <miles.parker@xxxxxxxxxxx> wrote: >> 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. Ok, I created a structure bridge for EMFStore and an UI structure bridge for EMF Client Platform (ECP) editors. In case someone needs something similar, they're available on github: https://github.com/sschmidt/org.eclipse.mylyn.mft.emfstore I'm essentially overwriting the methods which convert between EObject <-> handleIdentifier and use the EMFStore ID instead of the object URI. Cheers, Sebastian ]]> Tue, 26 Feb 2013 22:15:16 GMT http://dev.eclipse.org/mhonarc/lists/mylyn-context-dev/msg00061.html mail@xxxxxxx (Sebastian Schmidt) Re: [mylyn-context-dev] MFT and EMF Client Platform http://dev.eclipse.org/mhonarc/lists/mylyn-context-dev/msg00060.html Yes, this is the downside of using non-semantic UUIDs in this way, I guess. 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 p... 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 ]]> Tue, 05 Feb 2013 18:10:28 GMT http://dev.eclipse.org/mhonarc/lists/mylyn-context-dev/msg00060.html miles.parker@xxxxxxx (Miles Parker) Re: [mylyn-context-dev] MFT and EMF Client Platform http://dev.eclipse.org/mhonarc/lists/mylyn-context-dev/msg00059.html Miles, Carsten, thank you very much for pointing me in the right direction. We're using EMFStore as a backend to share/version our models. What happens is, that EMFStore doesn't use the Eclipse workspace for local copies of projects, but maintaines an own workspace (by default in the user's home directory). That said, I think MFT's behavior is perfectly fine - trying to provide the absolute path to the model objects in this case. 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. So I guess I'll try to come up with another structure bridge which inherits from EmfStructureBridge and supports this special case. 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 ]]> Tue, 05 Feb 2013 09:16:18 GMT http://dev.eclipse.org/mhonarc/lists/mylyn-context-dev/msg00059.html mail@xxxxxxx (Sebastian Schmidt) Re: [mylyn-context-dev] MFT and EMF Client Platform http://dev.eclipse.org/mhonarc/lists/mylyn-context-dev/msg00058.html 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 f... 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 ]]> Mon, 04 Feb 2013 19:37:07 GMT http://dev.eclipse.org/mhonarc/lists/mylyn-context-dev/msg00058.html miles.parker@xxxxxxx (Miles Parker) Re: [mylyn-context-dev] MFT and EMF Client Platform http://dev.eclipse.org/mhonarc/lists/mylyn-context-dev/msg00057.html 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. On 04.02.2013 20:30, Carsten Reckord wrote: >> 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... 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. -- 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 ]]> Mon, 04 Feb 2013 19:33:53 GMT http://dev.eclipse.org/mhonarc/lists/mylyn-context-dev/msg00057.html reckord@xxxxxxx (Carsten Reckord) Re: [mylyn-context-dev] MFT and EMF Client Platform http://dev.eclipse.org/mhonarc/lists/mylyn-context-dev/msg00056.html Yes, thinking about it, that could quickly become a slippery slope... 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 rece... 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 ]]> Mon, 04 Feb 2013 19:30:58 GMT http://dev.eclipse.org/mhonarc/lists/mylyn-context-dev/msg00056.html reckord@xxxxxxx (Carsten Reckord)