Target Management 3.0 Plan

Last revised 22:00 CET Oct 11, 2007

Please send comments about this plan to the developer mailing list.

This document lays out the feature and API set for the next feature release of the Target Management Project after TM 2.0, designated TM release 3.0.

This project plan and associated requirements are the result of an open and transparent process and includes input from those who have expressed an interest in the project. The plan is not entirely static: to ensure the planning process is transparent and open to the entire Eclipse community, we (the Target Management Project Lead) post plans in an embryonic form and revise them throughout the release cycle. That said, the success of the project and its deliverables is solely dependent upon the contributions from its community membership. If you are interested in contributing to the project planning, or the delivery of its stated goals, you are more than welcome!

The first part of the plan deals with the important matters of release deliverables, release milestones, operating environments, compatibilities and dependencies. These are all things that need to be clear for any release, even if no features were to change.

The remainder of the plan consists of plan items which are listed here for complete reference, but tracked individually through bugzilla. With the previous release as the starting point, this is the plan for how we will enhance and improve it. Fixing bugs, improving test coverage, documentation, examples, performance tuning, usability, etc. are considered routine ongoing maintenance activities and are not included in this plan unless they would also involve a significant change to the API or feature set, or involve a significant amount of work. The intent of the plan is to account for all interesting feature work.

Release deliverables

The Target Management Project provides data models, frameworks and tools for working with remote computer systems. The main deliverable is the Remote System Explorer (RSE), a feature-rich integrated perspective and toolkit for seamlessly working on remote systems. Besides that, we deliver flexible, re-usable components for Networking and Target Management that run stand-alone or integrated with RSE:

Notes: All stand-alone components will have an integration part that makes them work inside the RSE framework. For that reason, there are no downloadable stand-alone component tests, but the RSE unit test component will also have tests for the stand-alone components.

Release milestones

Release milestone will be occurring at roughly 6 week intervals, and will be aligned with the Ganymede Simultaneous Release train. Milestone names start with M3 in order to clarify this relationship. The milestones are:

Lock down and testing then begins with M7, and progress through a series of test-fix passes against candidates releases.
A detailed TM 3.0 Ramp down Plan towards the release is available especially for the Eclipse Ganymede Simultaneous Release integration.

As soon as no critical problems are found in the testing period between two release candidates (one or two weeks), a release candidate can be declared the release. The target date for availability of Target Management 3.0 is:

All release deliverables will be available for download as soon as the release has been tested and validated in the operating environments listed below.

Operating Environments

In order to remain current, each Eclipse release is designed to run on reasonably current versions of the underlying operating environments.

The Target Management Project 3.0 depends upon on the Eclipse Platform 3.4. Various sub components also depend on other Eclipse Projects, namely the C/C++ Development Tools (CDT) 4.0 and the Eclipse Modeling Framework (EMF) 2.3. For this release, the RSE sources will be written and compiled against version 1.4.2 of the Java Platform APIs (i.e., Java 2 Platform, Release 1.4.2 SE), and designed to run on version 1.4.2 of the Java Runtime Environment, Standard Edition. Since Java 5 is also used as Eclipse Reference Platform, some testing of Target Management will also be done on Java 5.

Eclipse Platform SDK 3.4 will be tested and validated on a number of reference platforms. The Target Management deliverables will be tested and validated against a subset of those listed for the platform, plus some more (marked (tm-only) ) for which contributors have have expressed special interest and volunteered to perform the systematic testing (this list is updated over the course of the release cycle).

Target Management Reference Platforms
Operating system OS version Processor architecture Window system Java 2 Platform
Microsoft Windows XP Intel x86 Win32 Sun Java 2 Standard Edition 5.0 Update 11
for Microsoft Windows
Microsoft Windows XP Intel x86 Win32 IBM 32-bit SDK for Windows,
Java 2 Technology Edition 5.0
Microsoft Windows (tm-only) 2000 Intel x86 Win32 Sun Java 2 Standard Edition 1.4.2_13 1.4.2_14
for Microsoft Windows
Red Hat Enterprise Linux WS 4 Intel x86 GTK Sun Java 2 Standard Edition 5.0 Update 8 Update 11
for Linux x86
SUSE Linux Enterprise Server 9 Intel x86 GTK IBM 32-bit SDK for Linux on Intel architecture,
Java 2 Technology Edition 1.4.2 service release 3
(tm-only) Ubuntu / Debian Linux 5.10 Intel x86 GTK Sun Java 2 Standard Edition 1.4.2_13
for Linux x86
Sun Solaris 9 SPARC GTK Sun Java 2 Standard Edition 5.0 Update 8 Update 11
for Solaris SPARC
Sun Solaris 9 SPARC Motif Sun Java 2 Standard Edition 5.0 Update 8
for Solaris SPARC
Apple Mac OS X 10.4 Power Carbon Java 2 Platform Standard Edition (J2SE) 1.4.2
service release 2 for Tiger

Eclipse and Target Management undoubtedly run fine in many operating environments beyond the reference platforms we test. However, since we do not systematically test them we cannot vouch for them. Problems encountered when running Target Management on a non-reference platform that cannot be recreated on any reference platform will be given lower priority than problems with running Target Management on a reference platform.

Although untested, Target Management should work fine on other OSes that support the same window system. For Win32: Windows 98, ME, NT, 2000, and Server 2003; SWT HTML viewer requires Internet Explorer 5 (or higher). For GTK on other Linux systems: version 2.2.1 of the GTK+ widget toolkit and associated libraries (GLib, Pango); SWT HTML viewer requires Mozilla 1.4GTK2. For more details, see the Eclipse Project Plan Reference Platforms.

Datastore Agent Reference Platforms

The Datastore protocol is the default protocol shipped with RSE for accessing remote file systems, process info and shells. It requires a Datastore server (agent) running on the remote system. This Datastore agent is shipped as plain Java Source Code together with the RSE distribution. It should run fine on any Java Platform, with additional Data Miner Plug-ins that may be OS specific.

We will test and verify the Datastore agent on the following Reference Platforms, which are a subset of the Platforms we test the RSE UI on:


The Remote System Explorer is designed as the basis for internationalized products. The user interface elements provided by the RSE components, including dialogs and error messages, are externalized. The English strings are provided as the default resource bundles. The default bundles will be localized to a subset of those locales offered by the Platform. This plan will be updated to indicate which locales will be provided and the timeframe for availability.

Compatibility and Dependencies

Dependencies of Release 2.0

Target Management takes part in the Ganymede Simultaneous Release Train. Therefore, deliverables will be developed in parallel with

Each Target Management Milestone Release will be based on the most recent Milestone releases of underlying components available at the time of release as well as the final releases.

Compatibility of Release 3.0 with 2.0

In order to evolve APIs and especially foster more UI/Non-UI separation, Target Management 3.0 will not be compatible with TM 2.0.

API Contract Compatibility: Target Management 3.0 will not be compatible with TM 2.0.

Binary (plug-in) Compatibility: Target Management 3.0 will not be compatible with TM 2.0.

Source Compatibility: Target Management 3.0 will not be compatible with TM 2.0, but a Target Management 3.0 Migration Guide will be published that explains how to port TM 2.0 applications to the TM 3.0 APIs. In most cases, "organize imports" should be sufficient in order to update API usage to classes refactored for better UI/Non-UI separation. Downward source compatibility is not supported.

Workspace Compatibility: We intend to keep Target Management 3.0 upwards workspace-compatible with TM 2.0 unless noted. This means that workspaces and projects created with TM 2.0 can be successfully opened by Target Mangement 3.0 and upgraded to a 3.0 workspace. This includes especially TM 2.0 connection definitions, which may propagate between workspaces via file copying or team repositories. User interface session state may be discarded when a workspace is upgraded. Downward workspace compatibility is not supported. A workspace created (or opened) by a product based on TM 3.0 will be unusable with a product based on TM 2.0.

API Contract

APIs published for the Target Management 3.0 release will be carefully reviewed prior to release, making use of "internal" packages for unsupported and variable implementation classes. Client plug-ins that directly depend on anything other than what is specified in the published API are inherently unsupportable and receive no guarantees about future compatibility. Refer to How to Use the Eclipse API for information about how to write compliant plug-ins.

Features and Capabilities

Plan items listed bleow were defined according to contributor requirements, but in accordance with the Target Management Use Cases Document and the Eclipse Themes and Priorities (Preliminary Roadmap v3) set forth by the Eclipse Requirments Council. Each plan item covers a feature or API that is to be added to the Target Management deliverables, or some aspect of the Target Management Project that is to be improved. Each plan item has its own entry in the Eclipse bugzilla database, with a title and a concise summary (usually a single paragraph) that explains the work item at a suitably high enough level so that everyone can readily understand what the work item is without having to understand the nitty-gritty detail.

Not all plan items represent the same amount of work; some may be quite large, others, quite small. Although some plan items are for work that is more pressing than others, the plan items appear in no particular order. Use the TM Project plan items bugzilla query for an up-to-date list. See the corresponding bugzilla items for up-to-date status information on ongoing work and planned delivery milestones.

The current status of each plan item is noted:

Committed Items

Contribute Import/Export from RSE7. The predecessor of Eclipse RSE was an IBM product, IBM RSE 7.0. Not all features of RSE 7.0 have been ported yet. For Eclipse RSE 2.0, we will port the Import/Export feature. Porting User actions and Compile Commands need to be deferred to a later release. While porting the feature, it will be refactored and optimized. See the link above for a presentation with more details about this feature. (Themes: Ease of Use, Enterprise Ready / Facilitated On-Boarding) (170909)

Allow encoding of remote files to be specified. Provide UI components for specifying the encoding of remote resources for cases where it differs from the standard Platform encoding. This will allow to transparently edit such remote resources properly. Also, support transparent re-encoding of resources when doing copy&paste or drag&drop between folders that require different encodings. (Theme: Enterprise Ready) (163820)

Improve Discovery and Autodetect in RSE. Support the use cases defined by the Autodetect Group, namely finding remote systems such that they can be added as RSE connections; and finding services on those systems and registering them with RSE connections. A single RSE connection should be used for a single remote system detected, adding support for the services detected. (Theme: Ease Of Use) (170911)

Improve UI/Non-UI splitting in RSE. RSE code should be further refactored to split UI from non-UI parts. This means providing non-UI (headless) APIs for accessing the SystemRegistry, getting IHost objects; getting ISubSystem, ISubSystemConfiguration objects as well as services; and using IFileServiceSubsystem as well as other ISubSystem and IService APIs for actions like upload, download, run-shell-command. Full support for headless Launches needs to be deferred to a later release. (Theme: Design for Extensibility) (170923)

Proposed Items

Adopt Eclipse Platform 3.3 concepts in RSE. TM should adopt Eclipse Platform concepts wherever possible. For instance, Move Commons Net packages into Orbit (needed for Europa); Improve drag&drop, copy&paste for Project Explorer, Package Explorer; Use Common Preferences for ssh and Proxy - Collaborate with Platform/Team on (170883); Adopt the Commands framework with retargetable actions (e.g. for Properties); Adopt ICU4J and Capabilities. (Theme: Persistent & Pervasive Themes; Ease of Use) (170915)

Fix and improve the RSE EFS integration. Given any files subsystem registered with RSE, RSE should be able to act as an EFS provider through that registered files subsystem. Current bugs with workspace resource locking should be fixed. In addition to that, it would be desirable to support an RSE subsystem under the Local system type that acts as an EFS browser, i.e. be able to access remote resources through any registered EFS provider. (Theme: Design for Extensibility) (170916)

Improve RSE SystemType and New Connection Wizard flexibility. ISVs need to be able to add new system types which are compatible with existing ones, and be able to automatically pick up subsystem implementations from 3rd parties that they don't know about initially. Additional states (and thus decorators) need to be considered by IHost objects and registered with systemTypes. More considerations need to be made for systemTypes that do not describe TCP/IP connections. Finally, contributors should be able to disable SystemTypes via capabilities and/or a dynamic enabler class. (Themes: Design for Extensibility, Embedded Device Software) (170918)

Optimize APIs - Remove obsolete API. RSE APIs should be made smaller (less API, more internal) in order to make them easier to understand and maintain. Eliminate dead code. Clarify threading model. Add asynchronous callbacks for long-runnint operations. (Theme: Design for Extensibility) (170922)

Improve the Remote File Service APIs. RSE File Service APIs should be sufficient to make a proper EFS provider. This means especially support for setting a file read-only / writable; changing a file's timestamp; preserving permissions when copying across systems; UI tools for reviewing / changing timestamp and read-only status; and returning potentially large remote files as streams for partial access, such that not the entire file is necessarily downloaded. In order to differenciate ourselves from EFS, we may add more tools that do not operate on an "abstract" file system but support more direct access to remote system's contributed permission and other status bits like Access Control Lists (ACLs). (Themes: Scaling Up, Design for Extensibility) (170926)

RSE should be more service-oriented. Currently, behavior of subsystems depends on the system type name they are registered against. Instead of this, Properties of system types should be used to modify subsystem behavior, such that existing subsystems can be added as services to more different system types. In addition to that, it should be possible to group services into a system; and support more dynamic enabling / disabling of subsystems / services based on availability. (Theme: Design for Extensibility) (150498)

Improve the RSE default Persistence Provider. For facilitated on-boarding, it should be easier to get access to pre-defined RSE connections out of a Team-Shared Repository or by importing/exporting connection definitions as XML. Fewer files should be used to store RSE state. It should be possible to associate connections, profiles, filter pools etc. with projects. Data storage should be flexible in the metadata or the project workspace, similar to the persistence mechanism used by Eclipse Launch Configurations today. (Theme: Enterprise Ready / Facilitated On-Boarding) (170932)

Add full support for Macintosh. MacOS X is a widespread Eclipse Platform and should be made official reference platform, thus giving bug reports a higher priority and doing automated unit testing regularly. (Theme: Platform Support) (170936)

Deferred Items

Contribute User Actions from RSE7. IBM RSE 7.0 User Actions and Compile Commands could not be ported to Eclipse TM RSE 2.0 in time due to lack of resources. They will be added in a later release. See the link above for a presentation with more details about these features. (Themes: Ease of Use, Enterprise Ready / Facilitated On-Boarding) (187395)

Support headless launches. Based on improved UI / non-UI splitting, a headless Eclipse should be able to perform Launches through RSE-provided services / subsystems. While a lot improvement has been made for RSE 2.0, a few roadblocks to full headless launch support could not be overcome due to lack of resources. (Theme: Design for Extensibility) (170923, 183771)

(new) Integrate the TM Terminal View with RSE. RSE provides a framework for registering data transfer protocols and managing connections. It provides a subsystem for executing commands on remote hosts through those protocols, but this is a line-oriented command view without terminal emulation. The current stand-alone TM Terminal View will be integrated with RSE as a new kind of subsystem that provides a terminal over any registered RSE IHostShell connection channel. (Theme: Ease Of Use) (170910)