Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search

E4/Resources/Definitions of Terms

< E4‎ | Resources
Revision as of 08:29, 14 November 2008 by Unnamed Poltroon (Talk)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

In order to be on the same page in E4 Resources development, we need to agree on a common definition of terms.
Feel free to edit, and watch this page for modifications until we can all agree on our definitions.
This page should be kept alphabetically sorted.

Important Ones

A "Folder" in the Resource system, the contents of which is driven by the file system (minus resource filtering).
In Eclipse 3.x, a Project is a non-overlapping portion in the file system, in order to manage stuff that belongs together. The project is responsible for persisting meta-data, and provides an extension point for tooling ("natures") to interpret this meta-data. "Linked Resources" allow associating the project with resources outside its managed tree, but this is the exception more than the standard case. Projects are identified by their unique name in the workspace.
In e4, we'll be looking at several extensions to what a project is:
  • Resource filters shall allow to completely hide unneeded stuff that just happens to physically reside under the project root by coincidence (bug 252996).
  • Linked Resources shall be better supported in order to allow a project manage "stuff that belongs together" even if that stuff is not under a common file system tree (bug 229633).
  • Virtual Folders shall allow to build smaller logical sub-groups of resources inside the project, regardless of their physical location, in order to manage them together more easily (bug 229633).
  • Projects shall be allowed to be physically nested in order to manage some "stuff that belongs together" as a project even if that stuff is nested under some folder that's managed by another project (bug 245412).
  • Other extensions are currently being discussed: pluggable persistence shemes, sharing of properties among projects, namespace resolution for multiple projects with the same name, extension to natures ("facets") with a common framework ("faceted project framework"), more flexible definition of views on the resources (multiple overlapping "Resource Sets" for various purposes)
Resource Filter
A filter being applied before nodes from the file system are actually entered into the Eclipse Resource model (Workspace) - bug 252996).
Resource Set
Generalization of current Eclipse UI Working sets: A set of resources (Containers or Files or other Resource Sets) defined by enumeration or filtering patterns (Is this a virtual folder?).
Collection of Resources (Projects) that is of interest to the user, and that needs to be seen on a global level. This global level includes registering for change notifications, and signing up for global services such as Search or Indexing such that the tooling can provide global information and search. In contrast, files outside the workspace can be edited but don't have the context (meta-info), global indexing, or change notification services that the workspace provides.
  • Large Workspaces currently present challenges to Eclipse in terms of Scalability. It would be interesting to allow multiple workspaces to be open concurrently (bug 245399, or make workspace switching faster, such that a workspace can be restricted to only those things that need to be in it. Multi-workspace might also allow optimizations in terms of per-workspace preferences and settings or having some workspaces not located locally. This is also related to a proposed two-tier approach of projects organized as "solutions" -- a "solution" could be implemented as a "workspace" if multi-workspace is supported.
  • Another option to improve scalability might be to allow more loose connection of resources with the workspace ("lazy resources"). Right now, a resource is either part of the workspace with all its services, or it is not. For some kinds of resources, it may be interesting to be e.g. part of an index but not take part in change notifications ("read-only resources").

Simple Ones

A link (redirection) created either by the resource system (linked resource) or by the file system (symbolic link, or other kind of file system based link).
From EFS, a reference to a folder (which can have files as children) or file (which can provide input and output streams) and have some attributes defined by the file system.
Linked Resource
A file or folder that is associated with a different file system sub-tree than its parent resource
An annotation on a resource, consisting of a set of String, int, and boolean attributes. This is used to represent breakpoints, problems, tasks, search results, etc. Often, but not necessarily, a marker is associated with a particular line or region of a text file. Markers get moved along with the resource during refactorings. For aliased resources, a marker is currently only associated with one resource in the set of aliases (which can create problems).
Persistent Property
A String attribute associated with a resource that is stored on disk and persists across sessions (does it get moved with the Resource during refactorings?.
A deleted resource that still resides in the resource tree as a place-holder for sync info
A FileStore plus state information, maintained by the Resource System.
Session Property
A String attribute associated with a resource that is stored in memory and does not persist across sessions.
Sync Info
A byte[] attribute stored on a resource intended to store synchronization state between a local resource and some remote counterpart. Sync info is maintained even when a resource is deleted.

Back to the top