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.

In terms of interfaces to other Eclipse projects, we provide an
Eclipse Filesystem (EFS) provider to allow remote resources be
mapped into an Eclipse Workspace. The DLTK and CDT projects are
other Eclipse projects known to integrate with Target Management.
PTP and PDT can use TM services via the underlying DLTK and CDT
layers. Several Eclipse Packages include TM (The Eclipse for Web
package, for instance, includes the TM Terminal).

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.

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.4 depends upon on the Eclipse Platform 4.2 or 3.8.
For this release, the RSE sources will mostly 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 except for the following components,
which are compiled on and running against Java 5:
FTP, Telnet and Import/Export.

The Target Management deliverables will be tested and validated against a
subset of the reference platforms listed in the
Eclipse Platform 4.2 Project Plan
(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

SP3

x86 32-bit

Win32

IBM Java 6 SR9

Microsoft Windows 7

SP1

x86 64-bit

Win32

Oracle Java 6 Update 27

Red Hat Enterprise Linux

WS 5 update 6

x86 64-bit

GTK

Oracle Java 6 Update 27
for Linux x86

SUSE Linux Enterprise Desktop

11.2

x86 64-bit

GTK

Oracle Java 6 Update 27

Apple Mac OS X (Secondary, see below)

10.6.8

Universal 64-bit

Cocoa

Apple Java 10.6 Update 5

Apple Mac OS X 10.5 is considered a "secondary" Reference Platform
meaning that it does receive some amount of systematic testing but
doesn't enjoy quite the same priority for bug fixes as the other
Platforms.

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.

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:

Red Hat Enterprise Linux 4, Intel x86, Oracle 1.5.0_14 VM

SUSE Linux Enterprise Server 10, Intel x86, IBM 1.4.2 sr 7 VM

Apple Mac OS X 10.5, Power, Apple J2SE 5 sr 4 VM

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.

Workspace Compatibility: We intend to keep Target Management
3.4 upwards workspace-compatible with TM 3.3 unless noted.
This means that workspaces and projects created with TM 3.3 can be successfully
opened by Target Management 3.4 and upgraded to a 3.4 workspace.
This includes especially TM 3.3 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.4 may be unusable
with a product based on TM 3.3.

API Contract

APIs published for the Target Management 3.4 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.

Plan items listed below were defined according to contributor requirements,
but in accordance with the Target Management
Use Cases Document and the Eclipse
Themes and Priorities
set forth by the Eclipse Requirements 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.
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 plan item - A committed plan item is one that we have
decided to address for the release. In bugzilla, this is reflected by
having a concrete target milestone assigned.

Proposed plan item - A proposed plan item is one that we are
considering addressing for the release. Although we are actively
investigating it, we are not yet in a position to commit to it, or to say
that we won't be able to address it. After due consideration, a proposal
will either be committed or deferred. In bugzilla, such items are reflected
by having a target milestone "3.4" assigned.

Deferred plan item - A reasonable proposal that will not make it in
to this release for some reason is marked as deferred with a brief note as
to why it was deferred. Deferred plan items may resurface as committed plan
items at a later point. In bugzilla, such items are reflected by having
a target milestone "Future" or "---" assigned.

For the constantly growing TM code size and committer base, it is important to have a
reliable but easy-to-use release engineering system. Required features include automatic
signing and adoption of Orbit, easy promoting to the Eclipse Servers and Juno,
running automated unit tests with automatic reporting of test failures to the mailing
lists, ability and description for running the releng build on any adopter's system.
We intend to adopt Tycho as the de-facto standard build
system at Eclipse in this release, and have our main builds run on the Eclipse Hudson
instance.
In bugzilla, items related to this theme are tagged with "[releng]" in the Summary
(query:
all [releng] open).

As the TM Codebase is growing, it is important to secure its functionality with
unit tests against regressions. Since large portions of RSE especially are UI
code, there should be an automated UI test suite run every night. Tests should
automatically run on all supported host platforms against all supported target
platforms. Adopters should be able to run a TM test suite on their own systems
easily, and configure it for sanity checking or compliance testing their own
connector plug-ins.
In bugzilla, these items are tagged with "[testing]" in the Summary
(query:
all [testing] open).

Eclipse 4.2 is the designate mainstream of Eclipse Platform development.
The TM project is committed to developing, running and testing
on the Eclipse 4.2 platform, and fixing defects as they are discovered.
In bugzilla, items related to Eclipse 4.x migration are tagged with "[4x]" in the Summary
(query:
all [testing] open).

Bug fixes for improved robustness, stability and usability are part of ongoing maintenance.
Besides that, here are some larger
features and bugs that we plan to address in the next release cycle until 3.4 M7, but are not categorized into one of the themes above.
<br>
In order not to overload the project plan with less important items, only those marked with a "plan" keyword will be
added to the project plan. The pool of known items to add to the plan can be found from the
associated queries
(query: all open
committed,
proposed,
deferred
).

The TM team uses Eclipse Bugzilla for all it's planning. Based on the plan item queries
listed above, the following consistency queries should never return any results: