platform-core-home/docs/eclipse-remote-dev-guidelines/remote-development.html
Parent Directory
| 
Revision Log
Revision 1.1 - (view) (download) (as text)
| 1 : | dj | 1.1 | <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> |
| 2 : | <html> | ||
| 3 : | <head> | ||
| 4 : | <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> | ||
| 5 : | <meta name="Author" content="Build"> | ||
| 6 : | <meta name="GENERATOR" content="Microsoft FrontPage 4.0"> | ||
| 7 : | <title>Eclipse Remote Development</title> | ||
| 8 : | </head> | ||
| 9 : | <body> | ||
| 10 : | |||
| 11 : | <h1> | ||
| 12 : | Eclipse Remote Development<br> | ||
| 13 : | Guidelines (Draft)</h1> | ||
| 14 : | <i><font size=-1>Last revised 16:30 Monday April 2, 2002</font></i> | ||
| 15 : | <p>The Eclipse Platform was designed to support a development model where both | ||
| 16 : | the relevant files (e.g., Java source code) and the required tools (e.g., Java | ||
| 17 : | compiler) reside on the developer's workstation. Call this is a <i>local | ||
| 18 : | development paradigm</i>. The Java development tooling (JDT) is the prime example | ||
| 19 : | of local development for Java programs. There are many environments where the | ||
| 20 : | primary tools reside only on a remote system distinct from the developer's | ||
| 21 : | workstation and, naturally enough, operate only on files that are directly | ||
| 22 : | available to that remote system. One concrete example of this is developing | ||
| 23 : | COBOL and RPG programs for IBM iSeries computers. Other examples include | ||
| 24 : | developing for mainframes or servers with legacy tools that do not exist in a | ||
| 25 : | compatible form outside that environment. A simple local development model is clearly | ||
| 26 : | inappropriate for these environments. One instead wants a <i>remote development | ||
| 27 : | paradigm</i> that factors in the fact that the user is dealing with tools and files on a | ||
| 28 : | system remote from the developer's workstation.</p> | ||
| 29 : | <p>This document explains how the Eclipse Platform can also be extended by | ||
| 30 : | plug-ins to support a remote development paradigm, and provides recommendations and | ||
| 31 : | guidelines for plug-in developers building remote development support.</p> | ||
| 32 : | <p>Table of contents:</p> | ||
| 33 : | <blockquote> | ||
| 34 : | <ul> | ||
| 35 : | <li><a href="#Eclipse Platform and local development">Eclipse Platform and local development</a></li> | ||
| 36 : | <li><a href="#Remote development with Eclipse Platform"> Remote development with Eclipse Platform</a></li> | ||
| 37 : | <li><a href="#Different modes of remote development">Different modes of remote development</a> | ||
| 38 : | <ul> | ||
| 39 : | <li><a href="#Eclipse remote development with workstation-resident file base">Eclipse remote development with workstation-resident file base</a> | ||
| 40 : | <ul> | ||
| 41 : | <li><a href="#Shared access to workstation-resident file base">Shared | ||
| 42 : | access to workstation-resident file base</a></li> | ||
| 43 : | <li><a href="#Replicate workstation-resident file base to remote system">Replicate workstation-resident file base to remote system</a></li> | ||
| 44 : | <li><a href="#Recommendations 1">Recommendations</a></li> | ||
| 45 : | </ul> | ||
| 46 : | </li> | ||
| 47 : | <li><a href="#Eclipse remote development with remote system-resident file base">Eclipse remote development with | ||
| 48 : | remote system-resident file base</a> | ||
| 49 : | <ul> | ||
| 50 : | <li><a href="#Shared access to remote system-resident file base">Shared | ||
| 51 : | access to remote system-resident file base</a></li> | ||
| 52 : | <li><a href="#Replicate remote system-resident file base to workstation">Replicate | ||
| 53 : | remote system-resident file base to workstation system</a></li> | ||
| 54 : | <li><a href="#Recommendations 2">Recommendations</a></li> | ||
| 55 : | </ul> | ||
| 56 : | </li> | ||
| 57 : | </ul> | ||
| 58 : | </li> | ||
| 59 : | <li><a href="#Conclusion">Conclusion</a></li> | ||
| 60 : | <li><a href="#Appendix: Eclipse Remote Development Example">Appendix: | ||
| 61 : | Eclipse Remote Development Example</a> | ||
| 62 : | <ul> | ||
| 63 : | <li><a href="#Variation 1 - Remote system-resident file base">Variation | ||
| 64 : | 1 - Remote system-resident file base</a></li> | ||
| 65 : | <li><a href="#Variation 2 - Workstation-resident file base">Variation 2 | ||
| 66 : | - Workstation-resident file base</a></li> | ||
| 67 : | </ul> | ||
| 68 : | </li> | ||
| 69 : | </ul> | ||
| 70 : | </blockquote> | ||
| 71 : | <h2><a name="Eclipse Platform and local development">Eclipse Platform and local development</a></h2> | ||
| 72 : | <p>This section reviews the Eclipse Platform's approach to local development. | ||
| 73 : | Many aspects are explained in more detail in the <a href="http://www.eclipse.org/whitepapers/eclipse-overview.pdf">Eclipse | ||
| 74 : | Platform Technical Overview (http://www.eclipse.org/whitepapers/eclipse-overview.pdf)</a>, | ||
| 75 : | which provides a high-level overview of the entire Eclipse Platform.</p> | ||
| 76 : | <p>The Eclipse <i>workbench</i> provides the UI personality of the Eclipse | ||
| 77 : | Platform, and supplies the structures in which tools interact with the user. The | ||
| 78 : | Eclipse Platform UI paradigm is based on editors, views, and perspectives: | ||
| 79 : | editors allow the user to open, edit, and save objects; views provide | ||
| 80 : | information about some object that the user is working with in the workbench; | ||
| 81 : | perspectives control the initial view visibility, layout, and action visibility | ||
| 82 : | for editors and views visible on the screen in the workbench window. Tools integrate into | ||
| 83 : | the editors-views-perspectives UI paradigm by extending the workbench with new types of | ||
| 84 : | editors, views, and perspectives, or by augmenting existing ones.<o:p></o:p> | ||
| 85 : | This is done via several workbench extension points. Eclipse provides a handful | ||
| 86 : | of standard views, editors, and perspectives, all contributed via these | ||
| 87 : | extension points.</p> | ||
| 88 : | <p>The Eclipse <i>workspace</i> | ||
| 89 : | consists of one or more top-level projects, | ||
| 90 : | where each project maps to a corresponding user-specified directory in the local | ||
| 91 : | file | ||
| 92 : | system. The different projects in a workspace map to different file system | ||
| 93 : | directories, possibly on different drives. A project contains files that are created and manipulated by the | ||
| 94 : | user; these files are directly accessible to the standard programs and | ||
| 95 : | tools of the underlying operating system, as well as to tools more tightly | ||
| 96 : | integrated with the Eclipse Platform. The Platform models projects, files, and | ||
| 97 : | folders (collectively termed resources) in the workspace and provides an API for | ||
| 98 : | operating on workspace resources. A workspace resource tree is maintained in | ||
| 99 : | memory at all times, allowing hierarchy navigation to be uniformly fast and | ||
| 100 : | independent of the speed of the underlying local file system. Resource change | ||
| 101 : | listeners give tools a reliable way to track changes | ||
| 102 : | to workspace resources by using after-the-fact notifications of all resource creations, | ||
| 103 : | deletions, and changes to the content of files. Event | ||
| 104 : | reports take the form of a tree of resource deltas describing the effect of the entire batch of operations in terms | ||
| 105 : | of net resource creations, deletions, and changes. Workspace resources can be | ||
| 106 : | annotated with markers and properties, and are adaptable so that other parties can extend their | ||
| 107 : | behavior. | ||
| 108 : | </p> | ||
| 109 : | <p>Although the workbench and workspace are typically used in conjunction, the | ||
| 110 : | central mechanisms for editors, views, and perspectives are independent of | ||
| 111 : | workspaces and resources. The primary workbench dependence on workspaces and resources is | ||
| 112 : | found in some of the standard views (notably the Navigator view and Tasks view) | ||
| 113 : | and in the standard text editors (which expect as input a file in the | ||
| 114 : | workspace). | ||
| 115 : | </p> | ||
| 116 : | <p>To support a local development paradigm in Eclipse, <o:p></o:p>a tool | ||
| 117 : | integrates with both the Eclipse workbench and the Eclipse workspace. The code | ||
| 118 : | for the tool runs on the workstation in the same process as the Eclipse | ||
| 119 : | Platform, contributes UI elements to the workbench, and operates on files found | ||
| 120 : | in projects in the workspace. This arrangement is called into question when we | ||
| 121 : | consider a remote development paradigm: the tools to be integrated do not exist | ||
| 122 : | on the workstation running Eclipse, and the files on which these remote tools | ||
| 123 : | operate are on the remote system rather than not on the workstation. | ||
| 124 : | </p> | ||
| 125 : | <p>For remote development, good integration with the Eclipse workbench is | ||
| 126 : | crucial (and as crucial as it is for local development) because it affects the | ||
| 127 : | overall user experience when running the Eclipse IDE. In principle, this is | ||
| 128 : | achievable with a tailor-made Eclipse Platform plug-in that (a) fronts for, and | ||
| 129 : | communicates with, tools running on the remote system, and (b) quietly | ||
| 130 : | orchestrates the behind-the-scenes shuffling of important data and files between | ||
| 131 : | the workstation and remote system. | ||
| 132 : | </p> | ||
| 133 : | <p>The key observation is that the | ||
| 134 : | plug-in that controls the UI and implements the underlying object model has <i>carte | ||
| 135 : | blanche</i>, and can make the user believe most anything it wants the user to | ||
| 136 : | think. In particular, it can present the user with objects that correspond to | ||
| 137 : | files on the remote system, and can do so regardless of whether the file is | ||
| 138 : | actually available as a local file in the workspace. As long as the user | ||
| 139 : | feels that the Eclipse IDE provides them with what they need to get their job | ||
| 140 : | done, there is considerable flexibility regarding when and how source files are | ||
| 141 : | materialized as resources in the Eclipse workspace. | ||
| 142 : | </p> | ||
| 143 : | <p>The main goal for any IDE is to provide for the developers' | ||
| 144 : | needs by giving them a familiar setting in which to develop kinds | ||
| 145 : | of programs (or web content, or whatever they are developing). In the Eclipse | ||
| 146 : | context, a second goal is to provide this support in a modular way via a plug-in | ||
| 147 : | (or family of related plug-ins) in a way that | ||
| 148 : | fits with the Eclipse workbench and with other installed plug-ins, allowing users | ||
| 149 : | to transition smoothly between heterogeneous tasks being done within the same | ||
| 150 : | IDE. Both of these overarching goals apply regardless of whether the files and tools | ||
| 151 : | are on the workstation or on a remote system. So in an important sense, the | ||
| 152 : | overall game is the same in all cases.</p> | ||
| 153 : | <p>Before delving in to how remote development can be made to work in Eclipse, | ||
| 154 : | it is useful to review how the standard Eclipse workbench and workspace | ||
| 155 : | facilities are used in practice. The following general guidelines outline recommended ways to support a | ||
| 156 : | local development paradigm with the Eclipse Platform:</p> | ||
| 157 : | <blockquote> | ||
| 158 : | <ol> | ||
| 159 : | <li> Use projects for coherent, long-lived development | ||
| 160 : | activities of a distinctive sort.</li> | ||
| 161 : | <li> Use a distinctive project capability (project nature) to mark the | ||
| 162 : | project.</li> | ||
| 163 : | <li>Define an object model for the entities of interest to the user.</li> | ||
| 164 : | <li>Use suitable views to present the object model to the user.</li> | ||
| 165 : | <li>Use actions to allow the user to manipulate the objects.</li> | ||
| 166 : | <li>Use a perspective to arrange high-interest views and editors | ||
| 167 : | to the user.</li> | ||
| 168 : | <li>Use suitable editors for editing objects.</li> | ||
| 169 : | </ol> | ||
| 170 : | </blockquote> | ||
| 171 : | <p> Java development tooling (JDT) is used as the example to illustrate how these | ||
| 172 : | guidelines are applied.</p> | ||
| 173 : | <p><b>1. Use projects for coherent, long-lived development | ||
| 174 : | activities of a distinctive sort.</b></p> | ||
| 175 : | <p>Projects in the Eclipse workspace are used to collect together the objects | ||
| 176 : | and files created and modified in the course of a long-lived development | ||
| 177 : | activity. Projects are also the standard unit for version and configuration | ||
| 178 : | management (VCM) and team support. The workbench gives the user general actions for creating, opening, | ||
| 179 : | closing, deleting, copying, and renaming projects. A single workspace may | ||
| 180 : | contain any number of projects. Using a project for any big ticket activity, | ||
| 181 : | even if it's just a shell of a project without any files or folders, affords | ||
| 182 : | 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 | ||
| 183 : | in a workspace. A multiplicity of projects is the norm.</p> | ||
| 184 : | <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 | ||
| 185 : | (named "Payroll") for this activity.</p> | ||
| 186 : | <p><b>2. Use a distinctive project capability (project nature) to mark the | ||
| 187 : | project.</b></p> | ||
| 188 : | <p>Projects in the Eclipse workspace are endowed with sets of project | ||
| 189 : | capabilities (new 2.0 mechanism) that determine in part how the project is | ||
| 190 : | presented to the user. Internally, project capabilities are implemented in terms | ||
| 191 : | of project natures (1.0 core mechanism). Giving a project a distinctive capability | ||
| 192 : | allows the project's presentation to be tailored appropriately. It is undesirable (and unnecessary) to presume that all projects in the | ||
| 193 : | workspace have comparable capabilities. Heterogeneity is the norm. It is also | ||
| 194 : | desirable to allow a single project to be configured with multiple capabilities; | ||
| 195 : | this makes it possible for a single project to support several related | ||
| 196 : | development activities.</p> | ||
| 197 : | <p>The user's "Payroll" project has the capability for developing Java | ||
| 198 : | programs (capabilities are usually acquired at | ||
| 199 : | project creation time, but can also be added or removed from any existing | ||
| 200 : | project). Internally, the project is tagged with a | ||
| 201 : | distinctive Java project nature. The Java capability can be used in conjunction | ||
| 202 : | with other capabilities (PDE is just one example).</p> | ||
| 203 : | <p><b>3. Maintain an object model for the entities of interest to the user.</b></p> | ||
| 204 : | <p>The object model is the Eclipse-side division of the relevant chunk of the | ||
| 205 : | world into objects. There is considerable flexibility in how an object model is | ||
| 206 : | built and maintained. Some objects might correspond directly to files | ||
| 207 : | (somewhere), while other might be synthesized from information gathered from | ||
| 208 : | multiple disparate sources.</p> | ||
| 209 : | <p>The JDT object model is known as the Java model. It models Java-specific | ||
| 210 : | objects called Java elements, including: Java projects, Java source files; type, | ||
| 211 : | method, and field declarations; packages directories; and JAR libraries. Each | ||
| 212 : | Java project has a single special classpath file (named ".classpath" | ||
| 213 : | and stored in the project's root directory of the project) that records | ||
| 214 : | Java-specific information about the project. This information includes the | ||
| 215 : | locations of the project's source folder(s), pre-compiled JAR libraries, and the | ||
| 216 : | output folder for compiler-generated binary class files. Java source files, and | ||
| 217 : | the generated binary class files, are stored as file resources in | ||
| 218 : | package-name-based folders under the Java project. JAR libraries, on the other | ||
| 219 : | hand, may be file resources in the workspace or files in the local file system | ||
| 220 : | beyond the workspace.</p> | ||
| 221 : | <p>Thus the Java model is generated from information lying both inside and outside the | ||
| 222 : | workspace. Essential information is generally kept in internal in-memory data structures to ensure that | ||
| 223 : | important object model | ||
| 224 : | navigations can be performed instantaneously; navigations which involve | ||
| 225 : | significant computation (e.g., opening source files and JARs, creating type | ||
| 226 : | hierarchies) are supported by API designed to allow internal caching but not | ||
| 227 : | force pre-computation or arbitrary retention of expensive structures. The Java | ||
| 228 : | model provides Java element deltas in the same spirit as workspace resource | ||
| 229 : | deltas, and uses resource markers to record compiler-detected problems against offending Java | ||
| 230 : | source files. </p> | ||
| 231 : | <p>Thus the Java model is designed to support the needs of the JDT UI and of | ||
| 232 : | client tools that present and manipulate Java code. And although much of the raw | ||
| 233 : | content of a Java project comes for files stored in that project, the | ||
| 234 : | relationship between the files resources in a Java project and Java model | ||
| 235 : | objects is far from a simple correspondence: some Java model objects correspond | ||
| 236 : | directly to workspace resources (e.g., Java project and source files); some | ||
| 237 : | files in the workspace project have no corresponding Java model objects (e.g., | ||
| 238 : | the generated class files); and some Java model objects do not correspond to | ||
| 239 : | workspace resources at all (e.g., declarations, and external JAR libraries).</p> | ||
| 240 : | <p><b>4. Use suitable views to present the object model to the user.</b></p> | ||
| 241 : | <p>The workbench UI window holds an arrangement of views and editors. Views | ||
| 242 : | present a selection of objects in the object model to the user and provide the | ||
| 243 : | main "handles" by which the user manipulates or otherwise interacts | ||
| 244 : | with model objects.</p> | ||
| 245 : | <p>The JDT Packages view is a navigator-like tree listing all (and only) Java projects in the | ||
| 246 : | workspace, with a tree of Java elements objects shown under each project. (This view presents a mix of objects from the workspace model | ||
| 247 : | (projects, source files) together with Java element objects.) The Eclipse JFace viewer framework makes it easy to define | ||
| 248 : | a content provider which feeds object model elements to the viewer, | ||
| 249 : | and a label provider to control the visual appearance (label and icon) of the | ||
| 250 : | items.</p> | ||
| 251 : | <p><b>5. Use object actions to allow the user to manipulate the objects.</b></p> | ||
| 252 : | <p>Objects shown in a view have associated actions which the user can see and | ||
| 253 : | select from the view's context menu.</p> | ||
| 254 : | <p>For example, Java elements like methods provide "delete" and | ||
| 255 : | "rename" actions with Java-specific meanings. The "open" action on these | ||
| 256 : | element opens a Java editor of the appropriate Java source file and scrolls the | ||
| 257 : | window to show the text of the method declaration.</p> | ||
| 258 : | <p>JDT also adapts the Eclipse launch framework to launch Java programs, and the | ||
| 259 : | Eclipse debugger framework to provide a | ||
| 260 : | debugger for Java programs.</p> | ||
| 261 : | <p><b>6. Use a perspective to arrange high-interest views and | ||
| 262 : | editors to the user.</b></p> | ||
| 263 : | <p>The initial choice and arrangement of views and editors in a workbench UI | ||
| 264 : | window is given by a workbench perspective. Perspectives help to reduce clutter | ||
| 265 : | and keep the user's attention focused on the task at hand.</p> | ||
| 266 : | <p>JDT provides a pre-defined Java perspective suited to Java development. It includes the | ||
| 267 : | Java Packages view, the standard workbench Tasks view, and an editor area.</p> | ||
| 268 : | <p><b>7. Use suitable editors for editing objects.</b></p> | ||
| 269 : | <p>Certain model objects have contents that the user can view and edit with a | ||
| 270 : | suitable editor, be it textual or graphical. Editors are most typically launched | ||
| 271 : | by a "open" action on objects shown in a view. The object's editable | ||
| 272 : | contents is read in to memory when the editor is launched; changes are written | ||
| 273 : | back when the user issues a "save" or "save as" command.</p> | ||
| 274 : | <p>The "open" action for a Java source file object opens a standard | ||
| 275 : | Eclipse text editor that has been specialized for editing Java source code. | ||
| 276 : | Standard text editors | ||
| 277 : | reading the contents of | ||
| 278 : | the file from the workspace, and the editor | ||
| 279 : | "save" action writes the modified buffer contents back to the file (or creates a new file in | ||
| 280 : | the case of "save as").</p> | ||
| 281 : | <h2> <a name="Remote development with Eclipse Platform"> Remote development with Eclipse Platform</a></h2> | ||
| 282 : | <p>With respect to supporting a remote development paradigm in Eclipse, the JDT | ||
| 283 : | example illustrates the following key ideas:</p> | ||
| 284 : | <ul> | ||
| 285 : | <li>Eclipse workspace integration is achieved chiefly through using projects, | ||
| 286 : | project capabilities, and file resources within the project.</li> | ||
| 287 : | <li>Eclipse workbench integration is achieved through suitable perspective, | ||
| 288 : | views, editors, and actions.</li> | ||
| 289 : | <li>The object model completely determines the objects the user gets to see | ||
| 290 : | and manipulate.</li> | ||
| 291 : | </ul> | ||
| 292 : | <p>The general approach for using Eclipse to develop programs on a remote system | ||
| 293 : | is obvious enough: | ||
| 294 : | </p> | ||
| 295 : | <ul> | ||
| 296 : | <li>Define a suitable | ||
| 297 : | project capability for remote development of the desired sort.</li> | ||
| 298 : | <li>Build a suitable object model including objects that correspond to things | ||
| 299 : | on the remote system. The canonical remote object is a file on the remote | ||
| 300 : | system.</li> | ||
| 301 : | <li>Build a suitable perspective, | ||
| 302 : | views, editors, and actions to show this object model to the user.</li> | ||
| 303 : | <li>Actions, such as ones on remote objects, communicate with tools running on the remote | ||
| 304 : | system.</li> | ||
| 305 : | <li>Editors opened on remote file objects access the contents of the file from | ||
| 306 : | the remote system, and stores the changed contents back sometime after | ||
| 307 : | editing is done.</li> | ||
| 308 : | </ul> | ||
| 309 : | <p>The interesting design question is how best to arrange for a source file to be | ||
| 310 : | available for editing on the workstation and also be available to the compiler | ||
| 311 : | running on the remote system.</p> | ||
| 312 : | <p>This turns out to be the crux of the matter, and key to understanding what | ||
| 313 : | role workspace resources can play and where a team repository could fit in this | ||
| 314 : | remote development picture.</p> | ||
| 315 : | <h2><a name="Different modes of remote development">Different modes of remote development</a></h2> | ||
| 316 : | <p>Up to this point we have been ignoring a very crucial question: Where do source files come | ||
| 317 : | from, and where do the changed source files need to end up? Although the simple "Hello World" example program gives the | ||
| 318 : | impression that all programs enter the development picture from the programmer's | ||
| 319 : | finger tips, this is hardly representative of what goes on in real life. In practice, source | ||
| 320 : | code is part and parcel of a file base that grows and evolves over a long period | ||
| 321 : | of time through the efforts of a team of developers. Before a developer can do | ||
| 322 : | any work, they must acquire a replica of the file base to work on. And when they are all through, the | ||
| 323 : | modified file base containing the source files that were changed must be put | ||
| 324 : | somewhere safe; otherwise, the changes would be lost, making the whole exercise | ||
| 325 : | pointless.</p> | ||
| 326 : | <p>If a developer is planning to do remote development, it is fair | ||
| 327 : | to ask where the file base containing the source files enters and exits the | ||
| 328 : | picture. There are two possibilities: the workstation or the remote system. Both | ||
| 329 : | may be valid ways of working in certain environments; both are different from | ||
| 330 : | each other; both can be supported.</p> | ||
| 331 : | <blockquote> | ||
| 332 : | <p><b>Workstation-resident file | ||
| 333 : | base</b> <b> </b>The source files enter and exit the picture at the workstation, | ||
| 334 : | exactly as they do in local development. Two common ways that this happens are (1) the developer accesses a team repository from their | ||
| 335 : | workstation, and (2) the developer unzips a source release into the workstation's | ||
| 336 : | local file system to be worked on there. Call this arrangement a <i>workstation-resident file | ||
| 337 : | base</i>. Since the files are available on the workstation, there is no real | ||
| 338 : | problem with editing them on the workstation. In this arrangement, the problem | ||
| 339 : | is making the files on the workstation available to tools that run on the remote | ||
| 340 : | system. </p> | ||
| 341 : | <p><b>Remote | ||
| 342 : | system-resident file base</b> The source files enter the picture at the remote system. Three common | ||
| 343 : | ways that this happens are (1) the developer accesses a file base from a pre-existing library | ||
| 344 : | on the remote system, (2) the developer accesses a team repository directly from the | ||
| 345 : | remote system, and (3) the developer unzips a source release into the remote | ||
| 346 : | system's local file system to be worked on there. Call this arrangement a <i>remote | ||
| 347 : | system-resident file base</i>. Since the files are available on the remote | ||
| 348 : | system, there is no real problem with accessing them from tools running on the | ||
| 349 : | remote system. In this arrangement, the problem is making the files on the | ||
| 350 : | remote system available to editors that run on the workstation.</p> | ||
| 351 : | </blockquote> | ||
| 352 : | <p>While workstation-resident file base and remote system-resident file base | ||
| 353 : | are similar in many respects, they are fundamentally different in important ways. | ||
| 354 : | Each has its own distinct problems and non-problems. Each has a solution | ||
| 355 : | involving similar mechanisms, although the mechanisms get used in subtly different ways. | ||
| 356 : | We consider each mode in turn, starting with the one that is closest to local | ||
| 357 : | development.</p> | ||
| 358 : | <h3><a name="Eclipse remote development with workstation-resident file base">Eclipse remote development with workstation-resident file base</a></h3> | ||
| 359 : | <p>With a workstation-resident file base, the workstation has a replica of the file | ||
| 360 : | base that is complete and accurate at all times. Any editing that happens | ||
| 361 : | affects this file base directly.</p> | ||
| 362 : | <p>As with a local development paradigm, the recommended location for this file | ||
| 363 : | base replica is inside the developer's Eclipse workspace, in the project content | ||
| 364 : | area of some project. In other words, the source files in the file base are | ||
| 365 : | stored as file resources under a suitable project in the Eclipse workspace. The | ||
| 366 : | user can use any general purpose Eclipse team provider, such as CVS, to provide | ||
| 367 : | team support and version and configuration management for the project's important files.</p> | ||
| 368 : | <p>There are two general approaches to making the file base on the workstation | ||
| 369 : | available to tools running on the remote system: shared access and replication.</p> | ||
| 370 : | <h4><b><a name="Shared access to workstation-resident file base">Shared access to workstation-resident file base</a></b></h4> | ||
| 371 : | <p>The shared access approach involves locating the content area for the project | ||
| 372 : | on a network file system drive that will be accessible to the | ||
| 373 : | remote system as well as to the workstation. The actual files might be stored on | ||
| 374 : | the workstation's local disk, on the remote system's local disk, or on the disk | ||
| 375 : | of a network file server. No matter. As long as both systems can access them.</p> | ||
| 376 : | <p>The advantage of this arrangement is simplicity: there are no replicas of the | ||
| 377 : | file base to get out of sync. Change made by editing the source file on the | ||
| 378 : | workstation are immediately visible to tools on the remote system. </p> | ||
| 379 : | <p>This arrangement supports offline editing in some circumstances. If the | ||
| 380 : | remote system becomes temporarily unavailable to the workstation, the user can | ||
| 381 : | continue editing as long as the file base is still available to the workstation. | ||
| 382 : | However, if the file base is actually stored on the local disk of the remote | ||
| 383 : | system, the user would be unable to do any work on that project while the remote | ||
| 384 : | system is offline or is otherwise disconnected from the workstation.</p> | ||
| 385 : | <p>This arrangement supports remote system retargeting: the user can switch an | ||
| 386 : | existing project to a different remote system as long as it can see the file | ||
| 387 : | base on the network file system drive.</p> | ||
| 388 : | <h4><b><a name="Replicate workstation-resident file base to remote system">Replicate workstation-resident file base to remote system</a></b></h4> | ||
| 389 : | <p>The workstation starts off with the replica of the file | ||
| 390 : | base that is complete and accurate; the remote system starts off without any | ||
| 391 : | part of the file base. </p> | ||
| 392 : | <p>This approach involves replicating the file base from the workstation to a | ||
| 393 : | corresponding area on the remote system. Since an Eclipse workspace is a | ||
| 394 : | developer's private sandbox, the corresponding area on the remote system should | ||
| 395 : | also be a private developer's sandbox. Under these conditions, replication is | ||
| 396 : | straightforward because it can always always be in one direction and there is no | ||
| 397 : | need to detect or resolve conflicts. Initially, the replica on the remote system | ||
| 398 : | is established by copying over the entire file base. Afterwards, it can be | ||
| 399 : | updated incrementally to match changes that happen to the master file base on | ||
| 400 : | the workstation. For instance, when the user edits a source file and saves the | ||
| 401 : | changes to their workspace file resource, the replica on the remote system | ||
| 402 : | becomes out of sync with the workstation. The changed file must be copied to the | ||
| 403 : | remote system to update the replica there, thereby bringing it back into sync. | ||
| 404 : | If resynchronization happens before a tool on the remote system accesses the | ||
| 405 : | replica, the workstation and remote system replicas will appear to behave as a | ||
| 406 : | seamless unit from the user's point of view. Eclipse Platform | ||
| 407 : | core target management provides infrastructure for building file synchronizers which | ||
| 408 : | can record and queue up batches of files that have been added, deleted, or changed. | ||
| 409 : | If the remote system replica is corrupted or becomes untrustworthy, it can be | ||
| 410 : | scrubbed and rebuilt from the workstation file base, which is always complete | ||
| 411 : | and the completely up to date.</p> | ||
| 412 : | <p>Figure 1 illustrates the general pattern of activity surrounding this kind of | ||
| 413 : | replication.</p> | ||
| 414 : | <p align="center"><img border="0" src="rd-wrfb.gif" width="647" height="300"><br> | ||
| 415 : | <br> | ||
| 416 : | Figure 1.Activity pattern in workstation-resident file base replicated to remote | ||
| 417 : | system</p> | ||
| 418 : | <p>The chief advantage of replicating over shared access is that this approach | ||
| 419 : | can be used in all environments, including ones where there is no network file | ||
| 420 : | system drive common to both systems. The chief expense of this arrangement is | ||
| 421 : | the cost of initial replication; the incremental maintenance of the replica is a | ||
| 422 : | lesser expense. Because the file base is actually copied from workstation to | ||
| 423 : | remote system under control of the remote development plug-in, there is | ||
| 424 : | maneuvering room to account for differences between the operating environments | ||
| 425 : | of the workstation and the remote system: file names and paths could be | ||
| 426 : | systematically remapped; and text file contents could be mapped to a code page | ||
| 427 : | more appropriate for the remote system.</p> | ||
| 428 : | <p>This arrangement also supports offline editing, and remote system retargeting | ||
| 429 : | at the cost of replicating the file base to each new remote target system.</p> | ||
| 430 : | <h4><a name="Recommendations 1">Recommendations</a></h4> | ||
| 431 : | <p>The replicating approach is generally recommended for all operating | ||
| 432 : | environments due to its flexibility, universal applicability, support for | ||
| 433 : | offline editing, and the ability to retarget to different a remote system. This | ||
| 434 : | approach is robust in the face of disconnections between the workstation and the | ||
| 435 : | remote system because the workstation always has the complete and perfectly | ||
| 436 : | up-to-date replica of the file base. As long as the workstation does not fail | ||
| 437 : | catastrophically, the connection to the remote system (or indeed the entire | ||
| 438 : | remote system) could be lost without the user losing important | ||
| 439 : | work.</p> | ||
| 440 : | <p>The shared access approach is recommended only in operating environments | ||
| 441 : | where all of the following conditions are true: (a) the network file system | ||
| 442 : | drive is accessible to the workstation and remote system at all times; (b) the | ||
| 443 : | network file system drive is fast enough to support the respective needs of each | ||
| 444 : | system; (c) file names and paths are identical on both systems; (d) the | ||
| 445 : | character encoding for text files are the same for both systems; (e) there is no | ||
| 446 : | problem with additional files created in the workstation project being visible | ||
| 447 : | to tools on the remote system; and (f) there is no need to interoperate with a | ||
| 448 : | team provider (or other plug-in) trying to play similar games by locating the | ||
| 449 : | content area of a workspace project on a special network file system drive | ||
| 450 : | (e.g., the Rational ClearCase team provider uses network file system drives for | ||
| 451 : | its dynamic views in some operating | ||
| 452 : | environments).</p> | ||
| 453 : | <h3><a name="Eclipse remote development with remote system-resident file base">Eclipse remote development with remote system-resident file base</a></h3> | ||
| 454 : | <p>With a remote system-resident file base, the problem that must be solved is | ||
| 455 : | making the files on the | ||
| 456 : | remote system available to editors that run on the workstation. Again, there are | ||
| 457 : | two general approaches: shared access and replication. Shared access is the | ||
| 458 : | same, but replication is different in some important respects.</p> | ||
| 459 : | <h4><b><a name="Shared access to remote system-resident file base">Shared access to remote system-resident file base</a></b></h4> | ||
| 460 : | <p>There is no difference between shared access to the remote system-resident | ||
| 461 : | file base and shared access to the workstation-resident file base. The approach | ||
| 462 : | has the same advantages and drawbacks as listed in the preceding section.</p> | ||
| 463 : | <h4><b><a name="Replicate remote system-resident file base to workstation">Replicate remote system-resident file base to | ||
| 464 : | workstation</a></b></h4> | ||
| 465 : | <p>The remote system starts off with the replica of the file | ||
| 466 : | base that is complete and accurate; the workstation starts off without any part | ||
| 467 : | of the file base. </p> | ||
| 468 : | <p>When the user opens an Eclipse editor on a remote file object, the contents | ||
| 469 : | to the file can be retrieved from the remote system file base and loaded into | ||
| 470 : | the editor's buffer. When the user saves the buffer, the modified contents can | ||
| 471 : | be stored back from the remote system overwriting the original file. All this | ||
| 472 : | can happen without the user having to be conscious of the fact that both systems | ||
| 473 : | are heavily involved. (Some standard Eclipse text editors operate exclusively on | ||
| 474 : | files in the workspace; the same is true for system editors which operate | ||
| 475 : | directly on files in the local file system and completely bypass the Eclipse | ||
| 476 : | workspace API. Using one of these editors requires the familiar dodge of | ||
| 477 : | materializing a temporary file in the workspace, opening the editor, sending | ||
| 478 : | back the changed contents when the temporary file is rewritten, and deleting the | ||
| 479 : | temporary file when the editor closes.) </p> | ||
| 480 : | <p>This simple scenario suggests that it is not absolutely necessary to | ||
| 481 : | replicate <i>any</i> files in the remote system file based to the Eclipse | ||
| 482 : | workspace on the workstation. An editor could work exclusively off a transient | ||
| 483 : | copy of the remote file's content; the file never need materialize as a file | ||
| 484 : | resource in the workspace project. Nevertheless, there are advantages to | ||
| 485 : | replicating <i>some</i> of the files in the remote file base to the workspace | ||
| 486 : | project.</p> | ||
| 487 : | <p>This approach involves selectively replicating files from the file base on | ||
| 488 : | the remote system to the workspace project. A file in the file base is | ||
| 489 : | replicated from remote system to workstation on request. When the user edits a | ||
| 490 : | source file and saves the changes to their workspace file resource, the replica | ||
| 491 : | on the remote system becomes out of sync with the workstation. The changed file | ||
| 492 : | must be copied back to the remote system to update the replica there, thereby | ||
| 493 : | bringing it back into sync. If resynchronization happens before a tool on the | ||
| 494 : | remote system accesses the replica, the workstation and remote system replicas | ||
| 495 : | will appear to behave as a seamless unit from the user's point of view.</p> | ||
| 496 : | <p>Maintaining a replica of selective files on the workstation improves | ||
| 497 : | performance over a pure remote approach because frequently edited files | ||
| 498 : | only have to be copied to the workstation once, as opposed to each time the | ||
| 499 : | editor is opened. The workstation replica also allows some offline editing that | ||
| 500 : | would be impossible in the pure remote approach.</p> | ||
| 501 : | <p>Figure 2 illustrates the general pattern of activity surrounding this kind of | ||
| 502 : | replication.</p> | ||
| 503 : | <p align="center"><img border="0" src="rd-rsrfb.gif" width="627" height="300"><br> | ||
| 504 : | <br> | ||
| 505 : | Figure 2.Activity pattern in remote system-resident file base replicated to | ||
| 506 : | workstation</p> | ||
| 507 : | <p>While superficially similar to replication involving a workstation-resident | ||
| 508 : | file base, the overall characteristics are quite different:</p> | ||
| 509 : | <ul> | ||
| 510 : | <li>The workstation usually has only a partial replica of the file base. (This | ||
| 511 : | is different. With a workstation-resident file base, the workstation always | ||
| 512 : | has a complete replica.)</li> | ||
| 513 : | <li>Systematic remapping of file names and paths between the systems is | ||
| 514 : | possible. (Same, although the mapping must be fully bi-directional.)</li> | ||
| 515 : | <li>Code page conversion of text file contents between the systems is | ||
| 516 : | possible. (Same, although the mapping must be fully bi-directional.)</li> | ||
| 517 : | <li>Creating a replica on the workstation involves copying from remote system | ||
| 518 : | to workstation. (Different. Copying never happens in this direction with a workstation-resident file | ||
| 519 : | base.)</li> | ||
| 520 : | <li>Resynchronizing after a file has been edited involves copying from | ||
| 521 : | workstation to remote system; the updates can be deferred, batched up, and | ||
| 522 : | done incrementally. (Same.)</li> | ||
| 523 : | <li>If the replicas on the workstation and remote system are in sync, the | ||
| 524 : | remote system has a complete and up-to-date file base. (Same.)</li> | ||
| 525 : | <li>If the replicas on the workstation and remote system are out of sync, | ||
| 526 : | neither system has a complete and up-to-date file base. (Different. The | ||
| 527 : | workstation always has a complete and up-to-date replica.)</li> | ||
| 528 : | <li>If the file base on the workstation is corrupted, the user loses important | ||
| 529 : | work (unless the systems happen to be in sync). (Same.)</li> | ||
| 530 : | <li>If the file base on the remote system is corrupted, the user loses | ||
| 531 : | important work. (Different. With a workstation-resident file base, the | ||
| 532 : | remote system file base is expendable, and can be rebuilt by scrubbing and | ||
| 533 : | recopying the workstation's file base.)</li> | ||
| 534 : | <li>If the connection to the remote system is lost, only files already | ||
| 535 : | replicated to the workstation will be available for editing while offline. | ||
| 536 : | (Different. All files are available for editing at all times with a workstation-resident file | ||
| 537 : | base.)</li> | ||
| 538 : | <li>If the connection to the remote system is lost while the workstation and | ||
| 539 : | remote system are out of sync, changed files in the workspace will be | ||
| 540 : | stranded in the workspace awaiting the connection to the remote system to be reestablished. (Different. | ||
| 541 : | In a workstation-resident file base, the remote system is not | ||
| 542 : | involved in ensuring that the changed files make it to save haven.)</li> | ||
| 543 : | <li>The workspace project cannot be retargeted to a different remote system | ||
| 544 : | without losing the file base. (Different. Retargeting is easy with a workstation-resident file | ||
| 545 : | base because the | ||
| 546 : | remote system is expendable.)</li> | ||
| 547 : | </ul> | ||
| 548 : | <p>Due to the fact that the putative master copy of the file base is kept on the | ||
| 549 : | remote system and not the workstation, general purpose Eclipse team providers | ||
| 550 : | associated with the workspace cannot provide VCM and team support for the | ||
| 551 : | project's important files. However, the remote system may have its own tools for version and configuration | ||
| 552 : | managing files and for supporting teams of developers working together. If it | ||
| 553 : | does, the obvious first approximation is to treat these tools much like other remote system | ||
| 554 : | tools: the plug-in that supports remote | ||
| 555 : | development should provides appropriate views and actions on remote | ||
| 556 : | objects to invoke these tools. </p> | ||
| 557 : | <p>Version 2.0 of the Eclipse Platform allows pluggable VCM and team support via team providers. | ||
| 558 : | Projects in the workspace can be assigned a team provider; each workspace | ||
| 559 : | project can have a different one. The recommended way to achieve good | ||
| 560 : | integration with the Eclipse workbench is to build special-purpose team | ||
| 561 : | providers for the various VCM and team products available on the remote system. | ||
| 562 : | The user could then be given a choice of suitable remote team providers for their | ||
| 563 : | remote projects.</p> | ||
| 564 : | <h4><a name="Recommendations 2">Recommendations</a></h4> | ||
| 565 : | <p>When the file base resides on the remote system, the replicating approach is | ||
| 566 : | generally recommended for all operating environments due to its flexibility, | ||
| 567 : | universal applicability, and support for limited offline editing. This approach | ||
| 568 : | is somewhat robust in the face of disconnections between the workstation and the | ||
| 569 : | remote system because the workstation always has the more up-to-date replicas of | ||
| 570 : | any files it has on hand. However, as long as there are files that have been | ||
| 571 : | changed in the workspace but not synchronized with the remote system, the user | ||
| 572 : | will not be able to reach closure until the remote system comes back online and | ||
| 573 : | their changes committed to the master copy of the file base.</p> | ||
| 574 : | <p>The shared access approach is recommended only in operating environments | ||
| 575 : | where all of the conditions listed in the earlier section are true. </p> | ||
| 576 : | <h2><a name="Conclusion">Conclusion</a></h2> | ||
| 577 : | <p>Workstation-resident file base and remote system-resident file base | ||
| 578 : | characterize the two main operating environments for remote development. Remote | ||
| 579 : | development with the Eclipse Platform can support either mode.</p> | ||
| 580 : | <p>The operating environment that is important to the majority of customers will | ||
| 581 : | likely dictate one approach over the other. For instance, there are extensive | ||
| 582 : | libraries of COBOL and RPG code that have always resided on the IBM iSeries and | ||
| 583 : | zSeries mainframe computers. This suggests treating them as having a remote | ||
| 584 : | system-resident file base. Full integration with Eclipse would require writing | ||
| 585 : | specialized team providers that work with existing VCM products native to these | ||
| 586 : | systems (e.g., Alden for the iSeries).</p> | ||
| 587 : | <p>On the other hand, there are a burgeoning number of hardware vendors making | ||
| 588 : | their high-end Linux systems available to open source developers to encourage | ||
| 589 : | porting and tuning of applications there (for example, the Open Source | ||
| 590 : | Development Lab at <a href="http://www.osdlab.org">http://www.osdlab.org</a>). | ||
| 591 : | In this case, the file base is not pre-existing on the remote system and full | ||
| 592 : | offline editing is desirable, which suggests a workstation-resident file base is | ||
| 593 : | appropriate. The open source developer loads the C/C++ code for their | ||
| 594 : | application from the CVS open source repository into their Eclipse workspace; | ||
| 595 : | the file base is then replicated to the remote system where it is compiled and | ||
| 596 : | run.</p> | ||
| 597 : | <p>Could a single remote development plug-in be built to support operating | ||
| 598 : | environments with either a workstation-resident file base or a remote | ||
| 599 : | system-resident file base? The answer is undoubtedly yes. Whether the extra work | ||
| 600 : | to support both would be worthwhile depends on the mix of customers being | ||
| 601 : | served.</p> | ||
| 602 : | <h2><a name="Appendix: Eclipse Remote Development Example">Appendix: Eclipse | ||
| 603 : | remote development example</a></h2> | ||
| 604 : | <p>This appendix walk through a simple example of remote development with | ||
| 605 : | Eclipse, just to show how the various elements come together in practice.</p> | ||
| 606 : | <h3><a name="Variation 1 - Remote system-resident file base">Variation 1 - Remote system-resident file base</a></h3> | ||
| 607 : | <p>As a hypothetical example of remote development, we consider how to let a | ||
| 608 : | user develop FOOBOL programs on a legendary HAL | ||
| 609 : | mainframe computer (of which there is only one remaining installation). Assume that | ||
| 610 : | great library of existing of FOOBOL source files reside on local disk file | ||
| 611 : | system of our HAL mainframe; assume that the developer's objective is to change some of | ||
| 612 : | these library source files, and occasionally add new ones to the library; and, | ||
| 613 : | finally, assume | ||
| 614 : | that the FOOBOL compiler already exists for the HAL mainframe, but would be too | ||
| 615 : | expensive to port to run on the workstation. Despite the example's crude | ||
| 616 : | simplicity, it does have the essential elements common to | ||
| 617 : | most remote development paradigms.</p> | ||
| 618 : | <p>This example is a clear cut case of a remote system-resident file base.</p> | ||
| 619 : | <p><b>1. Use projects for coherent, long-lived development | ||
| 620 : | activities of a distinctive sort.</b></p> | ||
| 621 : | <p>In our example, if the user is to develop a new payroll module in FOOBOL for | ||
| 622 : | their HAL mainframe, they can be expected to create themselves a new project | ||
| 623 : | (named "Payroll") for this activity.</p> | ||
| 624 : | <p><b>2. Use a distinctive project capability (project nature) to mark the | ||
| 625 : | project.</b></p> | ||
| 626 : | <p>The user's "Payroll" project has the capability for developing | ||
| 627 : | FOOBOL programs for a remote HAL system (capabilities are usually acquired at | ||
| 628 : | project creation time, but can also be added or removed from any existing | ||
| 629 : | project). Internally, the project would be tagged with a | ||
| 630 : | distinctive project nature.</p> | ||
| 631 : | <p><b>3. Maintain an object model for the entities of interest to the user.</b></p> | ||
| 632 : | <p>The FOOBOL user will be working with FOOBOL source code found in a library on | ||
| 633 : | the HAL file system. So the object model would naturally contain objects | ||
| 634 : | corresponding to FOOBOL source files. Internally, each file object would record | ||
| 635 : | the coordinates (URL) of the actual file on the HAL file system; this | ||
| 636 : | information is sufficient for identifying to both workstation and mainframe any | ||
| 637 : | particular source file. If the library uses path-structured names, then the | ||
| 638 : | object model would also contain objects corresponding to path prefixes | ||
| 639 : | (folders).</p> | ||
| 640 : | <p>The set of source files to be included in the object model might be as simple | ||
| 641 : | as all files in a particular subtree of the HAL file system, or might be a list of | ||
| 642 : | files in a variety of places hand-picked by the user. For simplicity, assume | ||
| 643 : | that it's the former. All "seed" information that is obtained from the | ||
| 644 : | user (the host name and port of the HAL computer, user id | ||
| 645 : | and password for authentication, root source directory, etc.) is remembered on disk so that it is not lost when the workspace is shutdown..</p> | ||
| 646 : | <p>Given the URL of the root directory, the names and URLs of all files in the | ||
| 647 : | source tree are obtained in a single round-trip to the HAL mainframe. The | ||
| 648 : | information returned is sufficient to generate the workstation object model. All | ||
| 649 : | essential information is generally kept in in-memory data structures to ensure that object model | ||
| 650 : | navigations can be performed instantaneously.</p> | ||
| 651 : | <p><b>4. Use suitable views to present the object model to the user.</b></p> | ||
| 652 : | <p>An appropriate main view for FOOBOL developer is a navigator-like view | ||
| 653 : | listing all (and only) FOOBOL projects in the workspace. The tree of FOOBOL | ||
| 654 : | source file objects are shown under each project. This view presents a mix of | ||
| 655 : | project objects, from the workspace object model, together with remote FOOBOL | ||
| 656 : | source file objects. The view is build with a standard JFace tree viewer and | ||
| 657 : | specialized content and label provider.</p> | ||
| 658 : | <p>When all objects that a user deals with are local, there is no value in | ||
| 659 : | calling attention to that fact. Likewise when all objects are remote. With a | ||
| 660 : | remote system-resident file base, any given FOOBOL source file object could be | ||
| 661 : | in one of 3 interesting states: on HAL only; in workspace and in sync; in | ||
| 662 : | workspace but out of sync. Which state a file is in may be quite important to | ||
| 663 : | the user: files in the workspace will be still available if disconnected from | ||
| 664 : | HAL, whereas others will not; out of sync files contain important changes that | ||
| 665 : | have not been safely captured, whereas files that are in sync are expendable and | ||
| 666 : | 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 | ||
| 667 : | does not pay to be too transparent about it. A specialized label provider | ||
| 668 : | provides special icon decorations that manifest important background information | ||
| 669 : | to the user.</p> | ||
| 670 : | <p><b>5. Use object actions to allow the user to manipulate the objects.</b></p> | ||
| 671 : | <p>FOOBOL source file objects have a "compile in background" action, | ||
| 672 : | which launches the FOOBOL compiler on the HAL mainframe with the name of the | ||
| 673 : | FOOBOL source file. The user continues to work while the compiler is running; | ||
| 674 : | when the compile finishes, the collected error messages are retrieved and displayed to | ||
| 675 : | the user | ||
| 676 : | as a text log in a FOOBOL compiler messages view. Individual error messages are | ||
| 677 : | also broken out and converted into markers. A special kind of problem marker is used to record the relevant source | ||
| 678 : | file and offending line. If the remote file is not available locally, these | ||
| 679 : | markers are placed instead on the "Payroll" | ||
| 680 : | project resource. The "open" action on these markers retrieves | ||
| 681 : | the contents of the appropriate FOOBOL source file from the HAL system and opens an | ||
| 682 : | editor on it.</p> | ||
| 683 : | <p>The Eclipse launch framework is adapted to launch FOOBOL programs to run on | ||
| 684 : | the remote HAL system, and the debugger framework is used when writing a remote | ||
| 685 : | debugger for FOOBOL programs running on the HAL system.</p> | ||
| 686 : | <p><b>6. Use a perspective to arrange high-interest views and | ||
| 687 : | editors to the user.</b></p> | ||
| 688 : | <p>For working on the "Payroll" project, a pre-defined FOOBOL | ||
| 689 : | perspective includes the FOOBOL project navigator view, the standard workbench | ||
| 690 : | Tasks view, and an editor. The FOOBOL compiler messages view appears when needed | ||
| 691 : | in the same place as the Tasks view.</p> | ||
| 692 : | <p><b>7. Use suitable editors for editing objects.</b></p> | ||
| 693 : | <p>The "open" action for a FOOBOL source file object opens a standard | ||
| 694 : | Eclipse text editor that has been specialized for editing FOOBOL source code with | ||
| 695 : | its fixed limit of 72 characters per line. The appropriate FOOBOL source file is | ||
| 696 : | copied from the HAL mainframe to the workspace if it is not already held | ||
| 697 : | locally. The user is informed whenever the | ||
| 698 : | FOOBOL source file being opened for editing is being copied locally, so that | ||
| 699 : | they can maintain a general background awareness of the whereabouts of their | ||
| 700 : | files, in case the connection to HAL system suddenly drops. The contents of | ||
| 701 : | the file is then read into memory by the editor; the editor | ||
| 702 : | "save" action writes the modified contents back to the file. The | ||
| 703 : | resource change callback signals that this file has changes which need to be | ||
| 704 : | sent to the HAL | ||
| 705 : | mainframe to replace the original source file contents. A specialized file synchronizer | ||
| 706 : | is used to remember which files have been added, deleted, and changed. During the movement of text between | ||
| 707 : | the HAL mainframe and the workstation, characters are converted between the | ||
| 708 : | particular HAL character encoding and Unicode, which is used universally in the Eclipse Platform | ||
| 709 : | and the Java 2 Platform. </p> | ||
| 710 : | <h3><a name="Variation 2 - Workstation-resident file base">Variation 2 - Workstation-resident file base</a></h3> | ||
| 711 : | <p>Let's change one assumption of the above example: assume that | ||
| 712 : | great library of existing of FOOBOL source files reside in public CVS | ||
| 713 : | repositories rather than on the local disk file | ||
| 714 : | system of our HAL mainframe. We now have a clear cut case of a | ||
| 715 : | workstation-resident file base. Consider how things change: </p> | ||
| 716 : | <p><b>1. Use projects for coherent, long-lived development | ||
| 717 : | activities of a distinctive sort.</b></p> | ||
| 718 : | <p>No change.</p> | ||
| 719 : | <p><b>2. Use a distinctive project capability (project nature) to mark the | ||
| 720 : | project.</b></p> | ||
| 721 : | <p>No change.</p> | ||
| 722 : | <p><b>3. Maintain an object model for the entities of interest to the user.</b></p> | ||
| 723 : | <p>No significant change. Even though the master copies of all HAL source files | ||
| 724 : | are in the workspace, the object model still orients the user to developing on | ||
| 725 : | the remote system.</p> | ||
| 726 : | <p><b>4. Use suitable views to present the object model to the user.</b></p> | ||
| 727 : | <p>No change.</p> | ||
| 728 : | <p><b>5. Use object actions to allow the user to manipulate the objects.</b></p> | ||
| 729 : | <p>No significant change. (Source files will always exist in the workspace to hang markers | ||
| 730 : | on.)</p> | ||
| 731 : | <p><b>6. Use a perspective to arrange high-interest views and | ||
| 732 : | editors to the user.</b></p> | ||
| 733 : | <p>No change.</p> | ||
| 734 : | <p><b>7. Use suitable editors for editing objects.</b></p> | ||
| 735 : | <p>No significant change. (There is never a need to copy a FOOBOL source file | ||
| 736 : | from the HAL system to the workspace.)</p> | ||
| 737 : | </body> | ||
| 738 : | </html> |
| help@eclipse.org | ViewVC Help |
| Powered by ViewVC 1.0.3 |