Project Plan For Target Management, version 3.4
Last revised 14:00 CET February 2, 2012.
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).Shortcut to Themes:
- Target Management source code release, available as versions tagged "R3_4" in the project's
- Remote System Explorer (RSE):
- RSE SDK (includes runtime, user and programmer documentation, with sources) (downloadable).
- RSE client runtime binaries (split up by protocol, includes user documentation) (downloadable).
- RSE dstore server runtime (downloadable).
- RSE User Actions and Compile Commands (downloadable).
- RSE tutorial code and examples (downloadable).
- RSE unit test framework and tests (downloadable).
- Stand-alone components:
- TM Terminal SDK (includes runtime, user and programmer documentation, with sources) (downloadable).
- Redistribution of Apache Commons Net 2.2 (downloadable through the Orbit project).
- Incubating components:
- RSE WinCE Subsystems and RAPI wrappers (runtime and sources) (downloadable).
- TM Local Terminal Connector (runtime and sources) (downloadable).
3.4M6 (API Freeze)
3.4M7 (Feature Freeze)
The target date for availability of Target Management 3.4 is:
- Wednesday June 27, 2012 - TM 3.4 Release date (with Juno)
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.
Although untested, Target Management should work fine on other OSes that support the same window system. For more details, see the Eclipse Project Plan 4.2 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:
- 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.
Target Management 3.4 will be backward compatible with TM 3.3.
API Contract Compatibility: Target Management 3.4 will be compatible with TM 3.3 as per the constraints documented in the TM 3.3 API Docs.
Binary (plug-in) Compatibility: Target Management 3.4 will be binary compatible with TM 3.3.
Source Compatibility: Target Management 3.4 will likely not be source compatible with TM 3.3.
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.
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.
Improve Release Engineering
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).
- No items.
- [releng] Broken 3.5 git tag  (target milestone: ---)
- [releng] The RSE "feature micro version" has not been updated for Juno SR2  (target milestone: ---)
- [releng] Integrate RSE-Useractions into RSE-Runtime  (target milestone: ---)
- [releng][wince] Trying to install WinCE on Linux with P2 gives odd error messages  (target milestone: ---)
- No items.
Improve Unittest Coverage
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).
- [testing] Need a unit test to exercise IFileService streams with multiple threads  (target milestone: ---)
- [testing] RSE Unittests should create "rsetest*" in /tmp instead of $HOME  (target milestone: ---)
- [testing] Add an RSE Unittest for SimpleCommandOperation  (target milestone: ---)
- [testing][local] 5 unittest failures in archive suite on Windows 7 64bit  (target milestone: ---)
- [testing] Error renaming in testCopyVirtualBatchToVirtualFileLevelOne  (target milestone: ---)
- [testing][regression] Some DStore Archive Testcases fail  (target milestone: Future)
Run on Eclipse 4.x
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).
- [4x][br][security] Adopt Equinox Secure Storage for RSE Passwords 
(target milestone: 3.4 M6)
- [4x][br][security] Adopt Equinox Secure Storage for RSE Passwords 
- No items.
- No items.
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 ).
- No items.
- [api] Align RSE Credential Management and Keystores with Platform Equinox  (target milestone: ---)
- Support X port forwarding for RSE SSH Terminals  (target milestone: 3.4)
- Support for SSH port forwarding (tunnelling)  (target milestone: ---)
- [performance][api] Performance optimization of IFileService.list() and IFileService.listMultiple()  (target milestone: ---)
- [performance] RSE fails to load with com.ibm.icu.base  (target milestone: ---)
- [usability][components] The Files, Processes, Shells wizard and property pages should be improved  (target milestone: ---)
- [usability][updating] Dirty remote editors do not get notified  (target milestone: ---)
- [components] Need generalized target descriptions  (target milestone: ---)
- [components][api] two or more subsystems of the same kind cannot be added to the same host  (target milestone: ---)
- [api] Request API to expand nodes in the system view to arbitrary level  (target milestone: ---)
- [usability][nls] The "port" property for FTP, SSH, Telnet should be in the New Connection Wizard  (target milestone: ---)
- Do not log messages shown as a result of invalid user input  (target milestone: Future)
- [filters] Grouping filters across subsystems  (target milestone: Future)
- Some RSE Logging should go to a hidden log rather than the PDE Errorlog  (target milestone: Future)
- [Persistence] Granular Persistence  (target milestone: Future)
- [performance] RSE should not process resource changes if not relevant  (target milestone: Future)
- [api] Need a Utility to send commands and receive output without prompt  (target milestone: Future)
- Dynamic filtering for the Remote System view  (target milestone: Future)
- [api] RSE needs improved refresh policies  (target milestone: Future)
- [api] Re-work and dramatically strip down SystemBaseAction and it's subclasses  (target milestone: Future)
- [api] Need API to change the Statusline shown for a custom subsystems  (target milestone: Future)
- Add Features to Remote Search view that are in the Search view  (target milestone: Future)
- [terminal][api] Need API to programmatically open the terminal for a specified connection  (target milestone: Future)
- [api] Need IHostShell#waitFor(), IHostShell#writeToShellAndWait()  (target milestone: Future)
- [dstore] Backward compatibility: Server and Daemon should support old clients  (target milestone: Future)
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:
- Target milestone "3.4", "---" or "Future" but resolved "FIXED": Query
- Keyword "performance" but not tagged "[performance]": Query
- Component "Terminal" but not tagged "[terminal]": Query
- Marked "FIXED" but still assigned to an "inbox": Query