Difference between revisions of "E4/Resources/Strawman"

Latest revision as of 15:59, 14 August 2009

This Straw man proposal presents a design and a list of work items towards evolving the Eclipse resource management system towards our e4 objectives. These objectives are documented in the other documents on this wiki site.

Overview

There are three layers to the resources architecture. Each layer builds on the facilities provided by the lower layers. This isn't actually much different that the current architecture.

File System Layer

The file system layer provides a common interface to resources that reside on various types of file system that accessible to Eclipse applications.

In the 3.x architecture, the Eclipse File System has a start on fulfilling that role. There are some short comings to EFS. In particular, it doesn't provide a rich enough API to fully represent the underlying file systems to Eclipse applications.

For e4, EFS will be extended to meet these objectives and to become a first class API in the resource management system. This include providing the ability for navigator views to browse and perform file system actions directly on this layer.

Project Layer

This is the traditional IResource layer we all know and love. The Project layer provides a view onto files in the File System layers and allows applications to provide semantics for different purposes.

The major change for e4 is that a Project becomes a file and folder list mapping IResources (resource) to IFileStores (file). Multiple resources can map to the same file. The facility that provides the file list is extensible. This could support the current Project structure, as well as provide facility to store the file list and metadata in a single file.

It also provides a mechanism for applications to attach metadata to resources. Along with 3.x's session and persistent properties, projects would also have properties that could be shared between users.

Application Layer

These are Eclipse applications that use and add semantics to resources in projects. The metadata facility from the Project layer can be used to persist metadata required to fulfill those semantics. For example, applications that provide build systems can store build settings in the metadata for the resource they build.

Other Resource Facilities

Resource Deltas

We need to be able to continue to provide this valuable feature of the resources system. This would continue to operate at the Project layer, and the information should be derived from change information provided by the file system.

With more control over the contents of a project, existing scalability concerns should be addressed.

Workspace

Workspaces become a project list and metadata, pretty much like today. Workspace storage should be extensible. In particular, it could be physically stored in a single file. This could impact applications that expect direct Java File access to files in the metadata folder.

Markers

Markers would continue to be associated with resources. We may wish to be able to take them to files in the File System layer for those items that affect all resource views on that file.

Components Affected by this Architecture

So how does this affect existing components and how can they benefit from this architecture.

Team Providers

The Team system would probably be most affected by this architecture, and could potentially benefit the most. It's a great example, that everyone should understand, of the need to make the File System a first class citizen. Source control systems have no connection to Eclipse and concepts like Projects are foreign to them.

The ClearCase Remote Client application from IBM/Rational provides a good example of how team systems should work. You start by using the source control system in a native mode, which checks out files and folders into a location on the local file system. From there, projects can be imported into the workspace.

Team operations should happen at the File System level. Team providers could even provide specialized file systems that map resources to "files" stored directly in the source control system, eliminating the need to copy to the local file system at all. (Not that this is likely to be built, but it could in this architecture).

IDEs

It's no secret that the CDT is having an influence on this architecture. The main architecture that the CDT provides is the ability to use Eclipse as a GUI front end to command-line based tools that C/C++ (and other language) developers have used in the past. As with the team tools, these external build and debug tools know only about the underlying file system, not of Eclipse Projects. To date, the facility to map IResources to Java Files has been overused to enable this functionality. This prevents these facilities to work remotely, e.g., remote builds.

To date, IDEs that work in this way have relied on the fact that Project/Resource hierarchy matches directly to the underlying file system. Facilities such as Linked Resources have caused hiccups in the past. This new architecture will lead to similar problems as all resources essentially become linked resources.