Eclipse Remote Development
Guidelines (Draft)

Last revised 16:30 Monday April 2, 2002

The Eclipse Platform was designed to support a development model where both the relevant files (e.g., Java source code) and the required tools (e.g., Java compiler) reside on the developer's workstation. Call this is a local development paradigm. The Java development tooling (JDT) is the prime example of local development for Java programs. There are many environments where the primary tools reside only on a remote system distinct from the developer's workstation and, naturally enough, operate only on files that are directly available to that remote system. One concrete example of this is developing COBOL and RPG programs for IBM iSeries computers. Other examples include developing for mainframes or servers with legacy tools that do not exist in a compatible form outside that environment. A simple local development model is clearly inappropriate for these environments. One instead wants a remote development paradigm that factors in the fact that the user is dealing with tools and files on a system remote from the developer's workstation.

This document explains how the Eclipse Platform can also be extended by plug-ins to support a remote development paradigm, and provides recommendations and guidelines for plug-in developers building remote development support.

Table of contents:

Eclipse Platform and local development

This section reviews the Eclipse Platform's approach to local development. Many aspects are explained in more detail in the Eclipse Platform Technical Overview (http://www.eclipse.org/whitepapers/eclipse-overview.pdf), which provides a high-level overview of the entire Eclipse Platform.

The Eclipse workbench provides the UI personality of the Eclipse Platform, and supplies the structures in which tools interact with the user. The Eclipse Platform UI paradigm is based on editors, views, and perspectives: editors allow the user to open, edit, and save objects; views provide information about some object that the user is working with in the workbench; perspectives control the initial view visibility, layout, and action visibility for editors and views visible on the screen in the workbench window. Tools integrate into the editors-views-perspectives UI paradigm by extending the workbench with new types of editors, views, and perspectives, or by augmenting existing ones. This is done via several workbench extension points. Eclipse provides a handful of standard views, editors, and perspectives, all contributed via these extension points.

The Eclipse workspace consists of one or more top-level projects, where each project maps to a corresponding user-specified directory in the local file system. The different projects in a workspace map to different file system directories, possibly on different drives. A project contains files that are created and manipulated by the user; these files are directly accessible to the standard programs and tools of the underlying operating system, as well as to tools more tightly integrated with the Eclipse Platform. The Platform models projects, files, and folders (collectively termed resources) in the workspace and provides an API for operating on workspace resources. A workspace resource tree is maintained in memory at all times, allowing hierarchy navigation to be uniformly fast and independent of the speed of the underlying local file system. Resource change listeners give tools a reliable way to track changes to workspace resources by using after-the-fact notifications of all resource creations, deletions, and changes to the content of files. Event reports take the form of a tree of resource deltas describing the effect of the entire batch of operations in terms of net resource creations, deletions, and changes. Workspace resources can be annotated with markers and properties, and are adaptable so that other parties can extend their behavior.

Although the workbench and workspace are typically used in conjunction, the central mechanisms for editors, views, and perspectives are independent of workspaces and resources. The primary workbench dependence on workspaces and resources is found in some of the standard views (notably the Navigator view and Tasks view) and in the standard text editors (which expect as input a file in the workspace).

To support a local development paradigm in Eclipse, a tool integrates with both the Eclipse workbench and the Eclipse workspace. The code for the tool runs on the workstation in the same process as the Eclipse Platform, contributes UI elements to the workbench, and operates on files found in projects in the workspace. This arrangement is called into question when we consider a remote development paradigm: the tools to be integrated do not exist on the workstation running Eclipse, and the files on which these remote tools operate are on the remote system rather than not on the workstation.

For remote development, good integration with the Eclipse workbench is crucial (and as crucial as it is for local development) because it affects the overall user experience when running the Eclipse IDE. In principle, this is achievable with a tailor-made Eclipse Platform plug-in that (a) fronts for, and communicates with, tools running on the remote system, and (b) quietly orchestrates the behind-the-scenes shuffling of important data and files between the workstation and remote system. 

The key observation is that the plug-in that controls the UI and implements the underlying object model has carte blanche, and can make the user believe most anything it wants the user to think. In particular, it can present the user with objects that correspond to files on the remote system, and can do so regardless of whether the file is actually available as a local file in the workspace. As long as the user feels that the Eclipse IDE provides them with what they need to get their job done, there is considerable flexibility regarding when and how source files are materialized as resources in the Eclipse workspace.

The main goal for any IDE is to provide for the developers' needs by giving them a familiar setting in which to develop kinds of programs (or web content, or whatever they are developing). In the Eclipse context, a second goal is to provide this support in a modular way via a plug-in (or family of related plug-ins) in a way that fits with the Eclipse workbench and with other installed plug-ins, allowing users to transition smoothly between heterogeneous tasks being done within the same IDE. Both of these overarching goals apply regardless of whether the files and tools are on the workstation or on a remote system. So in an important sense, the overall game is the same in all cases.

Before delving in to how remote development can be made to work in Eclipse, it is useful to review how the standard Eclipse workbench and workspace facilities are used in practice. The following general guidelines outline recommended ways to support a local development paradigm with the Eclipse Platform:

  1. Use projects for coherent, long-lived development activities of a distinctive sort.
  2. Use a distinctive project capability (project nature) to mark the project.
  3. Define an object model for the entities of interest to the user.
  4. Use suitable views to present the object model to the user.
  5. Use actions to allow the user to manipulate the objects.
  6. Use a perspective to arrange high-interest views and editors to the user.
  7. Use suitable editors for editing objects.

Java development tooling (JDT) is used as the example to illustrate how these guidelines are applied.

1. Use projects for coherent, long-lived development activities of a distinctive sort.

Projects in the Eclipse workspace are used to collect together the objects and files created and modified in the course of a long-lived development activity. Projects are also the standard unit for version and configuration management (VCM) and team support. The workbench gives the user general actions for creating, opening, closing, deleting, copying, and renaming projects. A single workspace may contain any number of projects. Using a project for any big ticket activity, even if it's just a shell of a project without any files or folders, affords the user a way to multi-task by switching between projects at their discretion. It is undesirable (and unnecessary) to presume that there would only be one project in a workspace. A multiplicity of projects is the norm.

For example, if the user is to develop a new payroll applet in Java, they can be expected to create themselves a new project (named "Payroll") for this activity.

2. Use a distinctive project capability (project nature) to mark the project.

Projects in the Eclipse workspace are endowed with sets of project capabilities (new 2.0 mechanism) that determine in part how the project is presented to the user. Internally, project capabilities are implemented in terms of project natures (1.0 core mechanism). Giving a project a distinctive capability allows the project's presentation to be tailored appropriately. It is undesirable (and unnecessary) to presume that all projects in the workspace have comparable capabilities. Heterogeneity is the norm. It is also desirable to allow a single project to be configured with multiple capabilities; this makes it possible for a single project to support several related development activities.

The user's "Payroll" project has the capability for developing Java programs (capabilities are usually acquired at project creation time, but can also be added or removed from any existing project). Internally, the project is tagged with a distinctive Java project nature. The Java capability can be used in conjunction with other capabilities (PDE is just one example).

3. Maintain an object model for the entities of interest to the user.

The object model is the Eclipse-side division of the relevant chunk of the world into objects. There is considerable flexibility in how an object model is built and maintained. Some objects might correspond directly to files (somewhere), while other might be synthesized from information gathered from multiple disparate sources.

The JDT object model is known as the Java model. It models Java-specific objects called Java elements, including: Java projects, Java source files; type, method, and field declarations; packages directories; and JAR libraries. Each Java project has a single special classpath file (named ".classpath" and stored in the project's root directory of the project) that records Java-specific information about the project. This information includes the locations of the project's source folder(s), pre-compiled JAR libraries, and the output folder for compiler-generated binary class files. Java source files, and the generated binary class files, are stored as file resources in package-name-based folders under the Java project. JAR libraries, on the other hand, may be file resources in the workspace or files in the local file system beyond the workspace.

Thus the Java model is generated from information lying both inside and outside the workspace. Essential information is generally kept in internal in-memory data structures to ensure that important object model navigations can be performed instantaneously; navigations which involve significant computation (e.g., opening source files and JARs, creating type hierarchies) are supported by API designed to allow internal caching but not force pre-computation or arbitrary retention of expensive structures. The Java model provides Java element deltas in the same spirit as workspace resource deltas, and uses resource markers to record compiler-detected problems against offending Java source files. 

Thus the Java model is designed to support the needs of the JDT UI and of client tools that present and manipulate Java code. And although much of the raw content of a Java project comes for files stored in that project, the relationship between the files resources in a Java project and Java model objects is far from a simple correspondence: some Java model objects correspond directly to workspace resources (e.g., Java project and source files); some files in the workspace project have no corresponding Java model objects (e.g., the generated class files); and some Java model objects do not correspond to workspace resources at all (e.g., declarations, and external JAR libraries).

4. Use suitable views to present the object model to the user.

The workbench UI window holds an arrangement of views and editors. Views present a selection of objects in the object model to the user and provide the main "handles" by which the user manipulates or otherwise interacts with model objects.

The JDT Packages view is a navigator-like tree listing all (and only) Java projects in the workspace, with a tree of Java elements objects shown under each project. (This view presents a mix of objects from the workspace model (projects, source files) together with Java element objects.) The Eclipse JFace viewer framework makes it easy to define a content provider which feeds object model elements to the viewer, and a label provider to control the visual appearance (label and icon) of the items.

5. Use object actions to allow the user to manipulate the objects.

Objects shown in a view have associated actions which the user can see and select from the view's context menu.

For example, Java elements like methods provide "delete" and "rename" actions with Java-specific meanings. The "open" action on these element opens a Java editor of the appropriate Java source file and scrolls the window to show the text of the method declaration.

JDT also adapts the Eclipse launch framework to launch Java programs, and the Eclipse debugger framework to provide a debugger for Java programs.

6. Use a perspective to arrange high-interest views and editors to the user.

The initial choice and arrangement of views and editors in a workbench UI window is given by a workbench perspective. Perspectives help to reduce clutter and keep the user's attention focused on the task at hand.

JDT provides a pre-defined Java perspective suited to Java development. It includes the Java Packages view, the standard workbench Tasks view, and an editor area.

7. Use suitable editors for editing objects.

Certain model objects have contents that the user can view and edit with a suitable editor, be it textual or graphical. Editors are most typically launched by a "open" action on objects shown in a view. The object's editable contents is read in to memory when the editor is launched; changes are written back when the user issues a "save" or "save as" command.

The "open" action for a Java source file object opens a standard Eclipse text editor that has been specialized for editing Java source code. Standard text editors reading the contents of the file from the workspace, and the editor "save" action writes the modified buffer contents back to the file (or creates a new file in the case of "save as").

Remote development with Eclipse Platform

With respect to supporting a remote development paradigm in Eclipse, the JDT example illustrates the following key ideas:

The general approach for using Eclipse to develop programs on a remote system is obvious enough:

The interesting design question is how best to arrange for a source file to be available for editing on the workstation and also be available to the compiler running on the remote system.

This turns out to be the crux of the matter, and key to understanding what role workspace resources can play and where a team repository could fit in this remote development picture.

Different modes of remote development

Up to this point we have been ignoring a very crucial question: Where do source files come from, and where do the changed source files need to end up? Although the simple "Hello World" example program gives the impression that all programs enter the development picture from the programmer's finger tips, this is hardly representative of what goes on in real life. In practice, source code is part and parcel of a file base that grows and evolves over a long period of time through the efforts of a team of developers. Before a developer can do any work, they must acquire a replica of the file base to work on. And when they are all through, the modified file base containing the source files that were changed must be put somewhere safe; otherwise, the changes would be lost, making the whole exercise pointless.

If a developer is planning to do remote development, it is fair to ask where the file base containing the source files enters and exits the picture. There are two possibilities: the workstation or the remote system. Both may be valid ways of working in certain environments; both are different from each other; both can be supported.

Workstation-resident file base  The source files enter and exit the picture at the workstation, exactly as they do in local development. Two common ways that this happens are (1) the developer accesses a team repository from their workstation, and (2) the developer unzips a source release into the workstation's local file system to be worked on there. Call this arrangement a workstation-resident file base. Since the files are available on the workstation, there is no real problem with editing them on the workstation. In this arrangement, the problem is making the files on the workstation available to tools that run on the remote system. 

Remote system-resident file base  The source files enter the picture at the remote system. Three common ways that this happens are (1) the developer accesses a file base from a pre-existing library on the remote system, (2) the developer accesses a team repository directly from the remote system, and (3) the developer unzips a source release into the remote system's local file system to be worked on there. Call this arrangement a remote system-resident file base. Since the files are available on the remote system, there is no real problem with accessing them from tools running on the remote system. In this arrangement, the problem is making the files on the remote system available to editors that run on the workstation.

While workstation-resident file base and remote system-resident file base are similar in many respects, they are fundamentally different in important ways. Each has its own distinct problems and non-problems. Each has a solution involving similar mechanisms, although the mechanisms get used in subtly different ways. We consider each mode in turn, starting with the one that is closest to local development.

Eclipse remote development with workstation-resident file base

With a workstation-resident file base, the workstation has a replica of the file base that is complete and accurate at all times. Any editing that happens affects this file base directly.

As with a local development paradigm, the recommended location for this file base replica is inside the developer's Eclipse workspace, in the project content area of some project. In other words, the source files in the file base are stored as file resources under a suitable project in the Eclipse workspace. The user can use any general purpose Eclipse team provider, such as CVS, to provide team support and version and configuration management for the project's important files.

There are two general approaches to making the file base on the workstation available to tools running on the remote system: shared access and replication.

Shared access to workstation-resident file base

The shared access approach involves locating the content area for the project on a network file system drive that will be accessible to the remote system as well as to the workstation. The actual files might be stored on the workstation's local disk, on the remote system's local disk, or on the disk of a network file server. No matter. As long as both systems can access them.

The advantage of this arrangement is simplicity: there are no replicas of the file base to get out of sync. Change made by editing the source file on the workstation are immediately visible to tools on the remote system. 

This arrangement supports offline editing in some circumstances. If the remote system becomes temporarily unavailable to the workstation, the user can continue editing as long as the file base is still available to the workstation. However, if the file base is actually stored on the local disk of the remote system, the user would be unable to do any work on that project while the remote system is offline or is otherwise disconnected from the workstation.

This arrangement supports remote system retargeting: the user can switch an existing project to a different remote system as long as it can see the file base on the network file system drive.

Replicate workstation-resident file base to remote system

The workstation starts off with the replica of the file base that is complete and accurate; the remote system starts off without any part of the file base. 

This approach involves replicating the file base from the workstation to a corresponding area on the remote system. Since an Eclipse workspace is a developer's private sandbox, the corresponding area on the remote system should also be a private developer's sandbox. Under these conditions, replication is straightforward because it can always always be in one direction and there is no need to detect or resolve conflicts. Initially, the replica on the remote system is established by copying over the entire file base. Afterwards, it can be updated incrementally to match changes that happen to the master file base on the workstation. For instance, when the user edits a source file and saves the changes to their workspace file resource, the replica on the remote system becomes out of sync with the workstation. The changed file must be copied to the remote system to update the replica there, thereby bringing it back into sync. If resynchronization happens before a tool on the remote system accesses the replica, the workstation and remote system replicas will appear to behave as a seamless unit from the user's point of view. Eclipse Platform core target management provides infrastructure for building file synchronizers which can record and queue up batches of files that have been added, deleted, or changed. If the remote system replica is corrupted or becomes untrustworthy, it can be scrubbed and rebuilt from the workstation file base, which is always complete and the completely up to date.

Figure 1 illustrates the general pattern of activity surrounding this kind of replication.



Figure 1.Activity pattern in workstation-resident file base replicated to remote system

The chief advantage of replicating over shared access is that this approach can be used in all environments, including ones where there is no network file system drive common to both systems. The chief expense of this arrangement is the cost of initial replication; the incremental maintenance of the replica is a lesser expense. Because the file base is actually copied from workstation to remote system under control of the remote development plug-in, there is maneuvering room to account for differences between the operating environments of the workstation and the remote system: file names and paths could be systematically remapped; and text file contents could be mapped to a code page more appropriate for the remote system.

This arrangement also supports offline editing, and remote system retargeting at the cost of replicating the file base to each new remote target system.

Recommendations

The replicating approach is generally recommended for all operating environments due to its flexibility, universal applicability, support for offline editing, and the ability to retarget to different a remote system. This approach is robust in the face of disconnections between the workstation and the remote system because the workstation always has the complete and perfectly up-to-date replica of the file base. As long as the workstation does not fail catastrophically, the connection to the remote system (or indeed the entire remote system) could be lost without the user losing important work.

The shared access approach is recommended only in operating environments where all of the following conditions are true: (a) the network file system drive is accessible to the workstation and remote system at all times; (b) the network file system drive is fast enough to support the respective needs of each system; (c) file names and paths are identical on both systems; (d) the character encoding for text files are the same for both systems; (e) there is no problem with additional files created in the workstation project being visible to tools on the remote system; and (f) there is no need to interoperate with a team provider (or other plug-in) trying to play similar games by locating the content area of a workspace project on a special network file system drive (e.g., the Rational ClearCase team provider uses network file system drives for its dynamic views in some operating environments).

Eclipse remote development with remote system-resident file base

With a remote system-resident file base, the problem that must be solved is making the files on the remote system available to editors that run on the workstation. Again, there are two general approaches: shared access and replication. Shared access is the same, but replication is different in some important respects.

Shared access to remote system-resident file base

There is no difference between shared access to the remote system-resident file base and shared access to the workstation-resident file base. The approach has the same advantages and drawbacks as listed in the preceding section.

Replicate remote system-resident file base to workstation

The remote system starts off with the replica of the file base that is complete and accurate; the workstation starts off without any part of the file base. 

When the user opens an Eclipse editor on a remote file object, the contents to the file can be retrieved from the remote system file base and loaded into the editor's buffer. When the user saves the buffer, the modified contents can be stored back from the remote system overwriting the original file. All this can happen without the user having to be conscious of the fact that both systems are heavily involved. (Some standard Eclipse text editors operate exclusively on files in the workspace; the same is true for system editors which operate directly on files in the local file system and completely bypass the Eclipse workspace API. Using one of these editors requires the familiar dodge of materializing a temporary file in the workspace, opening the editor, sending back the changed contents when the temporary file is rewritten, and deleting the temporary file when the editor closes.) 

This simple scenario suggests that it is not absolutely necessary to replicate any files in the remote system file based to the Eclipse workspace on the workstation. An editor could work exclusively off a transient copy of the remote file's content; the file never need materialize as a file resource in the workspace project. Nevertheless, there are advantages to replicating some of the files in the remote file base to the workspace project.

This approach involves selectively replicating files from the file base on the remote system to the workspace project. A file in the file base is replicated from remote system to workstation on request. When the user edits a source file and saves the changes to their workspace file resource, the replica on the remote system becomes out of sync with the workstation. The changed file must be copied back to the remote system to update the replica there, thereby bringing it back into sync. If resynchronization happens before a tool on the remote system accesses the replica, the workstation and remote system replicas will appear to behave as a seamless unit from the user's point of view.

Maintaining a replica of selective files on the workstation improves performance over a pure remote approach  because frequently edited files only have to be copied to the workstation once, as opposed to each time the editor is opened. The workstation replica also allows some offline editing that would be impossible in the pure remote approach.

Figure 2 illustrates the general pattern of activity surrounding this kind of replication.



Figure 2.Activity pattern in remote system-resident file base replicated to workstation

While superficially similar to replication involving a workstation-resident file base, the overall characteristics are quite different:

Due to the fact that the putative master copy of the file base is kept on the remote system and not the workstation, general purpose Eclipse team providers associated with the workspace cannot provide VCM and team support for the project's important files. However, the remote system may have its own tools for version and configuration managing files and for supporting teams of developers working together. If it does, the obvious first approximation is to treat these tools much like other remote system tools: the plug-in that supports remote development should provides appropriate views and actions on remote objects to invoke these tools. 

Version 2.0 of the Eclipse Platform allows pluggable VCM and team support via team providers. Projects in the workspace can be assigned a team provider; each workspace project can have a different one. The recommended way to achieve good integration with the Eclipse workbench is to build special-purpose team providers for the various VCM and team products available on the remote system. The user could then be given a choice of suitable remote team providers for their remote projects.

Recommendations

When the file base resides on the remote system, the replicating approach is generally recommended for all operating environments due to its flexibility, universal applicability, and support for limited offline editing. This approach is somewhat robust in the face of disconnections between the workstation and the remote system because the workstation always has the more up-to-date replicas of any files it has on hand. However, as long as there are files that have been changed in the workspace but not synchronized with the remote system, the user will not be able to reach closure until the remote system comes back online and their changes committed to the master copy of the file base.

The shared access approach is recommended only in operating environments where all of the conditions listed in the earlier section are true. 

Conclusion

Workstation-resident file base and remote system-resident file base characterize the two main operating environments for remote development. Remote development with the Eclipse Platform can support either mode.

The operating environment that is important to the majority of customers will likely dictate one approach over the other. For instance, there are extensive libraries of COBOL and RPG code that have always resided on the IBM iSeries and zSeries mainframe computers. This suggests treating them as having a remote system-resident file base. Full integration with Eclipse would require writing specialized team providers that work with existing VCM products native to these systems (e.g., Alden for the iSeries).

On the other hand, there are a burgeoning number of hardware vendors making their high-end Linux systems available to open source developers to encourage porting and tuning of applications there (for example, the Open Source Development Lab at http://www.osdlab.org). In this case, the file base is not pre-existing on the remote system and full offline editing is desirable, which suggests a workstation-resident file base is appropriate. The open source developer loads the C/C++ code for their application from the CVS open source repository into their Eclipse workspace; the file base is then replicated to the remote system where it is compiled and run.

Could a single remote development plug-in be built to support operating environments with either a workstation-resident file base or a remote system-resident file base? The answer is undoubtedly yes. Whether the extra work to support both would be worthwhile depends on the mix of customers being served.

Appendix: Eclipse remote development example

This appendix walk through a simple example of remote development with Eclipse, just to show how the various elements come together in practice.

Variation 1 - Remote system-resident file base

As a hypothetical example of remote development, we consider how to let a user develop FOOBOL programs on a legendary HAL mainframe computer (of which there is only one remaining installation). Assume that great library of existing of FOOBOL source files reside on local disk file system of our HAL mainframe; assume that the developer's objective is to change some of these library source files, and occasionally add new ones to the library; and, finally, assume that the FOOBOL compiler already exists for the HAL mainframe, but would be too expensive to port to run on the workstation. Despite the example's crude simplicity, it does have the essential elements common to most remote development paradigms.

This example is a clear cut case of a remote system-resident file base.

1. Use projects for coherent, long-lived development activities of a distinctive sort.

In our example, if the user is to develop a new payroll module in FOOBOL for their HAL mainframe, they can be expected to create themselves a new project (named "Payroll") for this activity.

2. Use a distinctive project capability (project nature) to mark the project.

The user's "Payroll" project has the capability for developing FOOBOL programs for a remote HAL system (capabilities are usually acquired at project creation time, but can also be added or removed from any existing project). Internally, the project would be tagged with a distinctive project nature.

3. Maintain an object model for the entities of interest to the user.

The FOOBOL user will be working with FOOBOL source code found in a library on the HAL file system. So the object model would naturally contain objects corresponding to FOOBOL source files. Internally, each file object would record the coordinates (URL) of the actual file on the HAL file system; this information is sufficient for identifying to both workstation and mainframe any particular source file. If the library uses path-structured names, then the object model would also contain objects corresponding to path prefixes (folders).

The set of source files to be included in the object model might be as simple as all files in a particular subtree of the HAL file system, or might be a list of files in a variety of places hand-picked by the user. For simplicity, assume that it's the former. All "seed" information that is obtained from the user (the host name and port of the HAL computer, user id and password for authentication, root source directory, etc.) is remembered on disk so that it is not lost when the workspace is shutdown..

Given the URL of the root directory, the names and URLs of all files in the source tree are obtained in a single round-trip to the HAL mainframe. The information returned is sufficient to generate the workstation object model. All essential information is generally kept in in-memory data structures to ensure that object model navigations can be performed instantaneously.

4. Use suitable views to present the object model to the user.

An appropriate main view for FOOBOL developer is a navigator-like view listing all (and only) FOOBOL projects in the workspace. The tree of FOOBOL source file objects are shown under each project. This view presents a mix of project objects, from the workspace object model, together with remote FOOBOL source file objects. The view is build with a standard JFace tree viewer and specialized content and label provider.

When all objects that a user deals with are local, there is no value in calling attention to that fact. Likewise when all objects are remote. With a remote system-resident file base, any given FOOBOL source file object could be in one of 3 interesting states: on HAL only; in workspace and in sync; in workspace but out of sync. Which state a file is in may be quite important to the user: files in the workspace will be still available if disconnected from HAL, whereas others will not; out of sync files contain important changes that have not been safely captured, whereas files that are in sync are expendable and can be dropped from the local replica without loss of information. So while it is worthwhile to seamlessly integrate the remote with the local, it does not pay to be too transparent about it. A specialized label provider provides special icon decorations that manifest important background information to the user.

5. Use object actions to allow the user to manipulate the objects.

FOOBOL source file objects have a "compile in background" action, which launches the FOOBOL compiler on the HAL mainframe with the name of the FOOBOL source file. The user continues to work while the compiler is running; when the compile finishes, the collected error messages are retrieved and displayed to the user as a text log in a FOOBOL compiler messages view. Individual error messages are also broken out and converted into markers. A special kind of problem marker is used to record the relevant source file and offending line. If the remote file is not available locally, these markers are placed instead on the "Payroll" project resource. The "open" action on these markers retrieves the contents of the appropriate FOOBOL source file from the HAL system and opens an editor on it.

The Eclipse launch framework is adapted to launch FOOBOL programs to run on the remote HAL system, and the debugger framework is used when writing a remote debugger for FOOBOL programs running on the HAL system.

6. Use a perspective to arrange high-interest views and editors to the user.

For working on the "Payroll" project, a pre-defined FOOBOL perspective includes the FOOBOL project navigator view, the standard workbench Tasks view, and an editor. The FOOBOL compiler messages view appears when needed in the same place as the Tasks view.

7. Use suitable editors for editing objects.

The "open" action for a FOOBOL source file object opens a standard Eclipse text editor that has been specialized for editing FOOBOL source code with its fixed limit of 72 characters per line. The appropriate FOOBOL source file is copied from the HAL mainframe to the workspace if it is not already held locally. The user is informed whenever the FOOBOL source file being opened for editing is being copied locally, so that they can maintain a general background awareness of the whereabouts of their files, in case the connection to HAL system suddenly drops. The contents of the file is then read into memory by the editor; the editor "save" action writes the modified contents back to the file. The resource change callback signals that this file has changes which need to be sent to the HAL mainframe to replace the original source file contents. A specialized file synchronizer is used to remember which files have been added, deleted, and changed. During the movement of text between the HAL mainframe and the workstation, characters are converted between the particular HAL character encoding and Unicode, which is used universally in the Eclipse Platform and the Java 2 Platform. 

Variation 2 - Workstation-resident file base

Let's change one assumption of the above example: assume that great library of existing of FOOBOL source files reside in public CVS repositories rather than on the local disk file system of our HAL mainframe. We now have a clear cut case of a workstation-resident file base. Consider how things change: 

1. Use projects for coherent, long-lived development activities of a distinctive sort.

No change.

2. Use a distinctive project capability (project nature) to mark the project.

No change.

3. Maintain an object model for the entities of interest to the user.

No significant change. Even though the master copies of all HAL source files are in the workspace, the object model still orients the user to developing on the remote system.

4. Use suitable views to present the object model to the user.

No change.

5. Use object actions to allow the user to manipulate the objects.

No significant change. (Source files will always exist in the workspace to hang markers on.)

6. Use a perspective to arrange high-interest views and editors to the user.

No change.

7. Use suitable editors for editing objects.

No significant change. (There is never a need to copy a FOOBOL source file from the HAL system to the workspace.)