[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Remote EFS designs



On Thu, May 28, 2009 at 5:00 PM, James Blackburn <jamesblackburn@xxxxxxxxx> wrote:
2009/5/28 Sergey Prigogin <eclipse.sprigogin@xxxxxxxxx>:
> On Thu, May 28, 2009 at 1:42 PM, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
>>
>> 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.
>
> I disagree. IPath has getDevice() and isUNC() methods that don't make any
> sense for resources inside workspace. IPath has problems and limitations but
> so are other competing file representations (java.io.File and URI)

Well I agree that IPath can be easier to use. However it's been
basically deprecated by the Platform guys to support EFS.  So apart
from workspace relative stuff, I think URI is the lowest common
denominator, is it not?

Yes. The fact that you can't tell whether an IPath is a workspace relative path or a file system path makes it basically useless. Since it's an Eclipse interface, let it be Eclipse things, but for dealing with the external world, you need classes that you can trust, like File and URI, and make the Util classes you need to make them work for your.

BTW, strictly speaking URI path's don't necessarily map to file system paths either. They usually do, but something to consider.

Doug
 

James
>>
>>
>> To represent file system paths, you should really be using java.io.File
>> for local paths, or URIs more generally.
>>
>> Doug.
>
> -sergey
>>
>>
>> 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
>>
>
>
> _______________________________________________
> 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