Bug 122936 - IResource isLocal and setLocal should be deprecated
Summary: IResource isLocal and setLocal should be deprecated
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Resources (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 3.2 M5   Edit
Assignee: John Arthorne CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-06 12:15 EST by John Arthorne CLA
Modified: 2006-01-09 16:59 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Arthorne CLA 2006-01-06 12:15:49 EST
Build: I20050103

There is a skeleton of support in the IResource API for the notion of "non-local" resources.  A non-local resource is one with no contents in the local file system. I.e., it exists in the resource tree but not on disk.  In practice this is just a flag on the resource info, and setLocal just flips that flag.  There is no mechanism for fetching contents of non-local resources into the local file system.

To give some history, in the initial technology preview of Eclipse (prior to open sourcing), IResource was much more tightly coupled to a corresponding entity in a code repository.  The idea was that the resource tree structure could be fetched from the repository without contents for quick browsing, and the individual file contents could be lazily fetched from the repository as needed.  This approach was abanded prior to the 1.0 release, but some vestiges remain in the API.

In Eclipse 3.2 it is possible to create resources that are stored diretly in other file systems.  This will likely confuse API clients who notice the old "local" and "non-local" terminology.  All of this old API should be deprecated to make it clear that these concepts are not part of the new flexible workspace API.  A partial list:

IResource.setLocal
IResource.isLocal
IFolder.create(boolean, boolean, IProgressMonitor)

Existing behaviour must continue to be supported for API compatibility, but should be deprecated to discourage future use.
Comment 1 John Arthorne CLA 2006-01-09 16:59:06 EST
Done.