Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "CDT/designs/EFS"
(→Overview) |
(→Issues) |
||
| Line 7: | Line 7: | ||
EFS introduces some significant changes to the traditional notion of the workspace. The most important of these is that EFS abstracts away the notion that a particular physical filesystem is used to store data in the workspace. Pre-EFS, it was possible to operate directly on resources using Java classes such as java.io.File, however with EFS this relationship can no longer be assumed to work. The resource may be contained in a zip file, or may even be physically located on a different computer. | EFS introduces some significant changes to the traditional notion of the workspace. The most important of these is that EFS abstracts away the notion that a particular physical filesystem is used to store data in the workspace. Pre-EFS, it was possible to operate directly on resources using Java classes such as java.io.File, however with EFS this relationship can no longer be assumed to work. The resource may be contained in a zip file, or may even be physically located on a different computer. | ||
| − | For Eclipse plugins that operate entirely within the confines of the Eclipse platform, this is an easy issue to overcome; simply use the IResource interfaces, or where | + | For Eclipse plugins that operate entirely within the confines of the Eclipse platform, this is an easy issue to overcome; simply use the IResource interfaces, or where direct file/directory operations are required, fetch the IFileStore/IFileInfo interfaces using the resource URI. For CDT, however, a large portion of the functionality requires interaction with tools that are completely external to the Eclipse environment. Unfortunately, many of these tools are used to interact with ''files'': either those in the workspace, or other system files that are needed to create C/C++ applications. |
Revision as of 10:04, 2 October 2007
Overview
Eclipse Filesystem (EFS) support was added to the Eclipse Platform in version 3.2, and the conversion has been mostly completed in 3.3. However, CDT presents a much more complex and challenging environment for such a conversion process, and to date there has been no concerted effort to do so. With interest in remote development environments increasing, there is now enough momentum to attempt to transition CDT to be fully EFS compliant. The aim of this document is to provide a central resource for this conversion process.
Issues
EFS introduces some significant changes to the traditional notion of the workspace. The most important of these is that EFS abstracts away the notion that a particular physical filesystem is used to store data in the workspace. Pre-EFS, it was possible to operate directly on resources using Java classes such as java.io.File, however with EFS this relationship can no longer be assumed to work. The resource may be contained in a zip file, or may even be physically located on a different computer.
For Eclipse plugins that operate entirely within the confines of the Eclipse platform, this is an easy issue to overcome; simply use the IResource interfaces, or where direct file/directory operations are required, fetch the IFileStore/IFileInfo interfaces using the resource URI. For CDT, however, a large portion of the functionality requires interaction with tools that are completely external to the Eclipse environment. Unfortunately, many of these tools are used to interact with files: either those in the workspace, or other system files that are needed to create C/C++ applications.