| <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> |
| <html> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> |
| <meta name="Author" content="Build"> |
| <meta name="GENERATOR" content="Microsoft FrontPage 4.0"> |
| <title>Eclipse Remote Development</title> |
| </head> |
| <body> |
| |
| <h1> |
| Eclipse Remote Development<br> |
| Guidelines (Draft)</h1> |
| <i><font size=-1>Last revised 16:30 Monday April 2, 2002</font></i> |
| <p>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 <i>local |
| development paradigm</i>. 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 <i>remote development |
| paradigm</i> that factors in the fact that the user is dealing with tools and files on a |
| system remote from the developer's workstation.</p> |
| <p>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.</p> |
| <p>Table of contents:</p> |
| <blockquote> |
| <ul> |
| <li><a href="#Eclipse Platform and local development">Eclipse Platform and local development</a></li> |
| <li><a href="#Remote development with Eclipse Platform"> Remote development with Eclipse Platform</a></li> |
| <li><a href="#Different modes of remote development">Different modes of remote development</a> |
| <ul> |
| <li><a href="#Eclipse remote development with workstation-resident file base">Eclipse remote development with workstation-resident file base</a> |
| <ul> |
| <li><a href="#Shared access to workstation-resident file base">Shared |
| access to workstation-resident file base</a></li> |
| <li><a href="#Replicate workstation-resident file base to remote system">Replicate workstation-resident file base to remote system</a></li> |
| <li><a href="#Recommendations 1">Recommendations</a></li> |
| </ul> |
| </li> |
| <li><a href="#Eclipse remote development with remote system-resident file base">Eclipse remote development with |
| remote system-resident file base</a> |
| <ul> |
| <li><a href="#Shared access to remote system-resident file base">Shared |
| access to remote system-resident file base</a></li> |
| <li><a href="#Replicate remote system-resident file base to workstation">Replicate |
| remote system-resident file base to workstation system</a></li> |
| <li><a href="#Recommendations 2">Recommendations</a></li> |
| </ul> |
| </li> |
| </ul> |
| </li> |
| <li><a href="#Conclusion">Conclusion</a></li> |
| <li><a href="#Appendix: Eclipse Remote Development Example">Appendix: |
| Eclipse Remote Development Example</a> |
| <ul> |
| <li><a href="#Variation 1 - Remote system-resident file base">Variation |
| 1 - Remote system-resident file base</a></li> |
| <li><a href="#Variation 2 - Workstation-resident file base">Variation 2 |
| - Workstation-resident file base</a></li> |
| </ul> |
| </li> |
| </ul> |
| </blockquote> |
| <h2><a name="Eclipse Platform and local development">Eclipse Platform and local development</a></h2> |
| <p>This section reviews the Eclipse Platform's approach to local development. |
| Many aspects are explained in more detail in the <a href="http://www.eclipse.org/whitepapers/eclipse-overview.pdf">Eclipse |
| Platform Technical Overview (http://www.eclipse.org/whitepapers/eclipse-overview.pdf)</a>, |
| which provides a high-level overview of the entire Eclipse Platform.</p> |
| <p>The Eclipse <i>workbench</i> 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.<o:p></o:p> |
| This is done via several workbench extension points. Eclipse provides a handful |
| of standard views, editors, and perspectives, all contributed via these |
| extension points.</p> |
| <p>The Eclipse <i>workspace</i> |
| 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. |
| </p> |
| <p>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). |
| </p> |
| <p>To support a local development paradigm in Eclipse, <o:p></o:p>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. |
| </p> |
| <p>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. |
| </p> |
| <p>The key observation is that the |
| plug-in that controls the UI and implements the underlying object model has <i>carte |
| blanche</i>, 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. |
| </p> |
| <p>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.</p> |
| <p>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:</p> |
| <blockquote> |
| <ol> |
| <li> Use projects for coherent, long-lived development |
| activities of a distinctive sort.</li> |
| <li> Use a distinctive project capability (project nature) to mark the |
| project.</li> |
| <li>Define an object model for the entities of interest to the user.</li> |
| <li>Use suitable views to present the object model to the user.</li> |
| <li>Use actions to allow the user to manipulate the objects.</li> |
| <li>Use a perspective to arrange high-interest views and editors |
| to the user.</li> |
| <li>Use suitable editors for editing objects.</li> |
| </ol> |
| </blockquote> |
| <p> Java development tooling (JDT) is used as the example to illustrate how these |
| guidelines are applied.</p> |
| <p><b>1. Use projects for coherent, long-lived development |
| activities of a distinctive sort.</b></p> |
| <p>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.</p> |
| <p>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.</p> |
| <p><b>2. Use a distinctive project capability (project nature) to mark the |
| project.</b></p> |
| <p>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.</p> |
| <p>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).</p> |
| <p><b>3. Maintain an object model for the entities of interest to the user.</b></p> |
| <p>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.</p> |
| <p>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.</p> |
| <p>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. </p> |
| <p>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).</p> |
| <p><b>4. Use suitable views to present the object model to the user.</b></p> |
| <p>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.</p> |
| <p>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.</p> |
| <p><b>5. Use object actions to allow the user to manipulate the objects.</b></p> |
| <p>Objects shown in a view have associated actions which the user can see and |
| select from the view's context menu.</p> |
| <p>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.</p> |
| <p>JDT also adapts the Eclipse launch framework to launch Java programs, and the |
| Eclipse debugger framework to provide a |
| debugger for Java programs.</p> |
| <p><b>6. Use a perspective to arrange high-interest views and |
| editors to the user.</b></p> |
| <p>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.</p> |
| <p>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.</p> |
| <p><b>7. Use suitable editors for editing objects.</b></p> |
| <p>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.</p> |
| <p>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").</p> |
| <h2> <a name="Remote development with Eclipse Platform"> Remote development with Eclipse Platform</a></h2> |
| <p>With respect to supporting a remote development paradigm in Eclipse, the JDT |
| example illustrates the following key ideas:</p> |
| <ul> |
| <li>Eclipse workspace integration is achieved chiefly through using projects, |
| project capabilities, and file resources within the project.</li> |
| <li>Eclipse workbench integration is achieved through suitable perspective, |
| views, editors, and actions.</li> |
| <li>The object model completely determines the objects the user gets to see |
| and manipulate.</li> |
| </ul> |
| <p>The general approach for using Eclipse to develop programs on a remote system |
| is obvious enough: |
| </p> |
| <ul> |
| <li>Define a suitable |
| project capability for remote development of the desired sort.</li> |
| <li>Build a suitable object model including objects that correspond to things |
| on the remote system. The canonical remote object is a file on the remote |
| system.</li> |
| <li>Build a suitable perspective, |
| views, editors, and actions to show this object model to the user.</li> |
| <li>Actions, such as ones on remote objects, communicate with tools running on the remote |
| system.</li> |
| <li>Editors opened on remote file objects access the contents of the file from |
| the remote system, and stores the changed contents back sometime after |
| editing is done.</li> |
| </ul> |
| <p>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.</p> |
| <p>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.</p> |
| <h2><a name="Different modes of remote development">Different modes of remote development</a></h2> |
| <p>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.</p> |
| <p>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.</p> |
| <blockquote> |
| <p><b>Workstation-resident file |
| base</b> <b> </b>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 <i>workstation-resident file |
| base</i>. 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. </p> |
| <p><b>Remote |
| system-resident file base</b> 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 <i>remote |
| system-resident file base</i>. 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.</p> |
| </blockquote> |
| <p>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.</p> |
| <h3><a name="Eclipse remote development with workstation-resident file base">Eclipse remote development with workstation-resident file base</a></h3> |
| <p>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.</p> |
| <p>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.</p> |
| <p>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.</p> |
| <h4><b><a name="Shared access to workstation-resident file base">Shared access to workstation-resident file base</a></b></h4> |
| <p>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.</p> |
| <p>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. </p> |
| <p>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.</p> |
| <p>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.</p> |
| <h4><b><a name="Replicate workstation-resident file base to remote system">Replicate workstation-resident file base to remote system</a></b></h4> |
| <p>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. </p> |
| <p>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.</p> |
| <p>Figure 1 illustrates the general pattern of activity surrounding this kind of |
| replication.</p> |
| <p align="center"><img border="0" src="rd-wrfb.gif" width="647" height="300"><br> |
| <br> |
| Figure 1.Activity pattern in workstation-resident file base replicated to remote |
| system</p> |
| <p>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.</p> |
| <p>This arrangement also supports offline editing, and remote system retargeting |
| at the cost of replicating the file base to each new remote target system.</p> |
| <h4><a name="Recommendations 1">Recommendations</a></h4> |
| <p>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.</p> |
| <p>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).</p> |
| <h3><a name="Eclipse remote development with remote system-resident file base">Eclipse remote development with remote system-resident file base</a></h3> |
| <p>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.</p> |
| <h4><b><a name="Shared access to remote system-resident file base">Shared access to remote system-resident file base</a></b></h4> |
| <p>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.</p> |
| <h4><b><a name="Replicate remote system-resident file base to workstation">Replicate remote system-resident file base to |
| workstation</a></b></h4> |
| <p>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. </p> |
| <p>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.) </p> |
| <p>This simple scenario suggests that it is not absolutely necessary to |
| replicate <i>any</i> 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 <i>some</i> of the files in the remote file base to the workspace |
| project.</p> |
| <p>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.</p> |
| <p>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.</p> |
| <p>Figure 2 illustrates the general pattern of activity surrounding this kind of |
| replication.</p> |
| <p align="center"><img border="0" src="rd-rsrfb.gif" width="627" height="300"><br> |
| <br> |
| Figure 2.Activity pattern in remote system-resident file base replicated to |
| workstation</p> |
| <p>While superficially similar to replication involving a workstation-resident |
| file base, the overall characteristics are quite different:</p> |
| <ul> |
| <li>The workstation usually has only a partial replica of the file base. (This |
| is different. With a workstation-resident file base, the workstation always |
| has a complete replica.)</li> |
| <li>Systematic remapping of file names and paths between the systems is |
| possible. (Same, although the mapping must be fully bi-directional.)</li> |
| <li>Code page conversion of text file contents between the systems is |
| possible. (Same, although the mapping must be fully bi-directional.)</li> |
| <li>Creating a replica on the workstation involves copying from remote system |
| to workstation. (Different. Copying never happens in this direction with a workstation-resident file |
| base.)</li> |
| <li>Resynchronizing after a file has been edited involves copying from |
| workstation to remote system; the updates can be deferred, batched up, and |
| done incrementally. (Same.)</li> |
| <li>If the replicas on the workstation and remote system are in sync, the |
| remote system has a complete and up-to-date file base. (Same.)</li> |
| <li>If the replicas on the workstation and remote system are out of sync, |
| neither system has a complete and up-to-date file base. (Different. The |
| workstation always has a complete and up-to-date replica.)</li> |
| <li>If the file base on the workstation is corrupted, the user loses important |
| work (unless the systems happen to be in sync). (Same.)</li> |
| <li>If the file base on the remote system is corrupted, the user loses |
| important work. (Different. With a workstation-resident file base, the |
| remote system file base is expendable, and can be rebuilt by scrubbing and |
| recopying the workstation's file base.)</li> |
| <li>If the connection to the remote system is lost, only files already |
| replicated to the workstation will be available for editing while offline. |
| (Different. All files are available for editing at all times with a workstation-resident file |
| base.)</li> |
| <li>If the connection to the remote system is lost while the workstation and |
| remote system are out of sync, changed files in the workspace will be |
| stranded in the workspace awaiting the connection to the remote system to be reestablished. (Different. |
| In a workstation-resident file base, the remote system is not |
| involved in ensuring that the changed files make it to save haven.)</li> |
| <li>The workspace project cannot be retargeted to a different remote system |
| without losing the file base. (Different. Retargeting is easy with a workstation-resident file |
| base because the |
| remote system is expendable.)</li> |
| </ul> |
| <p>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. </p> |
| <p>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.</p> |
| <h4><a name="Recommendations 2">Recommendations</a></h4> |
| <p>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.</p> |
| <p>The shared access approach is recommended only in operating environments |
| where all of the conditions listed in the earlier section are true. </p> |
| <h2><a name="Conclusion">Conclusion</a></h2> |
| <p>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.</p> |
| <p>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).</p> |
| <p>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 <a href="http://www.osdlab.org">http://www.osdlab.org</a>). |
| 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.</p> |
| <p>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.</p> |
| <h2><a name="Appendix: Eclipse Remote Development Example">Appendix: Eclipse |
| remote development example</a></h2> |
| <p>This appendix walk through a simple example of remote development with |
| Eclipse, just to show how the various elements come together in practice.</p> |
| <h3><a name="Variation 1 - Remote system-resident file base">Variation 1 - Remote system-resident file base</a></h3> |
| <p>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.</p> |
| <p>This example is a clear cut case of a remote system-resident file base.</p> |
| <p><b>1. Use projects for coherent, long-lived development |
| activities of a distinctive sort.</b></p> |
| <p>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.</p> |
| <p><b>2. Use a distinctive project capability (project nature) to mark the |
| project.</b></p> |
| <p>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.</p> |
| <p><b>3. Maintain an object model for the entities of interest to the user.</b></p> |
| <p>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).</p> |
| <p>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..</p> |
| <p>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.</p> |
| <p><b>4. Use suitable views to present the object model to the user.</b></p> |
| <p>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.</p> |
| <p>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.</p> |
| <p><b>5. Use object actions to allow the user to manipulate the objects.</b></p> |
| <p>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.</p> |
| <p>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.</p> |
| <p><b>6. Use a perspective to arrange high-interest views and |
| editors to the user.</b></p> |
| <p>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.</p> |
| <p><b>7. Use suitable editors for editing objects.</b></p> |
| <p>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. </p> |
| <h3><a name="Variation 2 - Workstation-resident file base">Variation 2 - Workstation-resident file base</a></h3> |
| <p>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: </p> |
| <p><b>1. Use projects for coherent, long-lived development |
| activities of a distinctive sort.</b></p> |
| <p>No change.</p> |
| <p><b>2. Use a distinctive project capability (project nature) to mark the |
| project.</b></p> |
| <p>No change.</p> |
| <p><b>3. Maintain an object model for the entities of interest to the user.</b></p> |
| <p>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.</p> |
| <p><b>4. Use suitable views to present the object model to the user.</b></p> |
| <p>No change.</p> |
| <p><b>5. Use object actions to allow the user to manipulate the objects.</b></p> |
| <p>No significant change. (Source files will always exist in the workspace to hang markers |
| on.)</p> |
| <p><b>6. Use a perspective to arrange high-interest views and |
| editors to the user.</b></p> |
| <p>No change.</p> |
| <p><b>7. Use suitable editors for editing objects.</b></p> |
| <p>No significant change. (There is never a need to copy a FOOBOL source file |
| from the HAL system to the workspace.)</p> |
| </body> |
| </html> |
