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"
(→Issues) |
(→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. | ||
| − | Eclipse plugins that operate entirely within the confines of the Eclipse platform can overcome this issue relatively easily: 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 both workspace and non-workspace resouces. This is further complicated because the workspace resources may not even exist on the local machine, but instead may be accessed from a remote system. In this case, some, or all, of the tools themselves may need to be executed remotely in order to gain access to the resources. | + | Eclipse plugins that operate entirely within the confines of the Eclipse platform can overcome this issue relatively easily: 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 both workspace and non-workspace resouces. This is further complicated because the workspace resources may not even exist on the local machine, but instead may be accessed from a remote system. In this case, some, or all, of the tools themselves may need to be executed remotely in order to gain access to the resources. Running tools remotely like this is beyond the scope of this document, but still needs to be taken into consideration during the EFS conversion process. |
Revision as of 11:11, 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.
Eclipse plugins that operate entirely within the confines of the Eclipse platform can overcome this issue relatively easily: 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 both workspace and non-workspace resouces. This is further complicated because the workspace resources may not even exist on the local machine, but instead may be accessed from a remote system. In this case, some, or all, of the tools themselves may need to be executed remotely in order to gain access to the resources. Running tools remotely like this is beyond the scope of this document, but still needs to be taken into consideration during the EFS conversion process.