The resources component provides the fundamental model underlying the IDE portion of the Eclipse Platform. This includes the central concepts of resources (projects, folders, and files), builders, natures, resource change listeners, etc. The resources component contains no GUI, and can be run in a completely headless Eclipse application.
The resources component was historically part of the platform core component. The Platform core component was divided into RCP (runtime) and IDE (sections), and then further divided when the Equinox component was introduced with a new runtime for the Eclipse platform. Historical documents, plans, etc, can be found on the original Platform Core home page.
The resources component is comprised of the following plug-ins:
- org.eclipse.core.contenttype - plug-in providing API for detecting and managing file content types and encodings.
- org.eclipse.core.filesystem - An abstract, generic file system API, including an implementation of this API for the local file system. This is the API through which the resources plugin accesses an underlying file system.
- org.eclipse.core.filesystem.<os>.<arch> - various fragments containing platform-specific implementations of the local file system for EFS
- org.eclipse.core.resources - Contains the API and implementation of the resource model
- org.eclipse.core.resources.compatibility - A plug-in providing migration support for users opening old workspaces in Eclipse 3.1 or greater
- org.eclipse.core.resources.win32 - Provides extra Windows-specific features for the resources plug-in. Primarily, this contains native code for hooking into Windows callbacks that notify the resources plug-in when resources have been changed in the file system.
The core data structure of the workspace is the workspace tree (read the javadoc on the Workspace.tree field). The tree (ElementTree) contains a ResourceInfo object for each existing resource. All data associated with a given resource can be found on ResourceInfo, or on objects that it holds. Concurrent access to the tree is governed by the WorkManager class.
IResource objects are just handles that know where to look for their corresponding ResourceInfo in the tree. The existence of an IResource object is unrelated to whether the resource actually exists. You can have an IResource object that represents a non-existing resource, and you can have an existing resource for which no IResource object exists. Each time you ask IResource to do something, it goes looking for the actual resource in the tree.
This design is highly thread-safe, because all interesting data is stored in a single place: the workspace tree. Accessing or modifying any resource data requires a lookup in the tree, so synchronization is all handled in one central place. The ElementTree data structure allows N simultaneous reader threads, and one writer thread at any given time. I.e., the tree design does not require synchronization for readers (with the understanding that readers may sometimes get slightly stale information if a writer is modifying the tree at the same time).
Back to WorkspaceTeam