Re: [cdt-dev] Remote EFS designs

[James Blackburn <jamesblackburn@xxxxxxxxx>]

2009/5/28 Doug Schaefer <cdtdoug@xxxxxxxxx>:
> Something I'm beginning to understand is that IPath is not intended for file
> system paths. While it may work in some cases, it is really meant for
> workspaces paths.
>
> To represent file system paths, you should really be using java.io.File for
> local paths, or URIs more generally.

Yep, we learnt that yesterday ;).  When it comes to sharing projects
it's best to have everything workspace relative so as much as possible
can work when checked out in a different location.  You then have to
jump through hoops when converting too and from fs location for the
external tools.

Sadly the APIs for manipulating URIs are horrible. No append by
default, and different URIs depending on whether the file pointed to
by the URI exists or not...  Thankfully the platform provides two
URIUtil classes, not-so-good you need to use both as they provide
different functionality *sigh*.

James

>
> Doug.
>
> On Thu, May 28, 2009 at 4:31 PM, Andrew Gvozdev <angvoz.dev@xxxxxxxxx>
> wrote:
>>
>> Hi James,
>>
>> IPath <==> URI conversions are not always properly handled
>>
>> Consider the following example:
>>
>> IPath path = new Path("c:", "/a/b/c"); IFileStore f =
>> EFS.getLocalFileSystem().getStore(path); then print out f.toURI() you get
>> something like: file:/path/to/workspace/c:/a/b/c
>>
>> Lack of Windows path support
>>
>> There is no device field in a URI. I.e., it's not legal to have c: in a
>> URI.
>>
>> Is there any eclipse EFS URI specification to refer? It seems to be legal
>> to have ":" character in URI according RFC 2396. You may need to escape it
>> in case of conflicts with schema but it does not look that it is the case in
>> our case.
>>
>> Building projects: IResources -> Command Line Arguments
>> Include folders could be expressed using URI. So could build location in
>> project properties. I am not sure how far we want to go with that for now,
>> but suggest to add as part of collecting requirements.
>>
>> Resolving absolute paths
>> There is one more case deserving to be considered. The absolute path could
>> be outside of the project but in the workspace as part of some other
>> project. Not sure how important it is for generating makefile but it is very
>> important for parsing error output and assigning markers.
>> >Hi All,
>> > Feel free to edit / bring up issues you think I may have missed.
>> I don't think All has permissions to edit the page. If so could you
>> instruct how to do that.
>> Andrew
>>
>>
>> On Thu, May 28, 2009 at 12:08 PM, James Blackburn
>> <jamesblackburn@xxxxxxxxx> wrote:
>>>
>>> Hi All,
>>>
>>> We had a quick brainstorm about generating markers for build output
>>> for the case of remote builds using RDT, and how this might interact
>>> with e4 style flexible resources (effectively glorified linked
>>> resources).  I don't think there's much of issue apart from: make
>>> ErrorParserManager support URIs.
>>>
>>>
>>> I've added some detail to the EFS wiki :
>>> http://wiki.eclipse.org/PTP/designs/remote/EFS adding two sections:
>>> 1.1.1 FileStore layers & 1.4 Implementation Assumptions.
>>>
>>> This documents what was discussed. i.e. converting IResources to paths
>>> for the builder (which is done now) & the reverse: converting Tool
>>> output paths to IResources.
>>>
>>> The approach outlined is that any IResource may be linked, and may
>>> point to an arbitrary EFS URI.  The EFS URIs, are assumed to map to a
>>> filesystem tree of the same structure (this assumption is currently
>>> made by the RDT tools and elsewhere).    The job is then converting
>>> Console output paths to locationURIs to resolve.
>>>
>>> This approach allows fully flexible IResource trees (using Serge's e4
>>> work for ease + a few minor tweaks to ManagedBuild), and is working
>>> well here.  I see no reason why this shouldn't work nicely with RDT as
>>> it does for local file systems.
>>>
>>> Feel free to edit / bring up issues you think I may have missed.
>>>
>>> Cheers,
>>>
>>> James
>>>
>>
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>