Build Notes for TM 2.0
Jun 27, 2007

• TM 2.0 requires Eclipse 3.3 later for the SSH component. Other components may work with earlier Eclipse versions, but these have not been tested. Platform Runtime is the minimum requirement for core RSE and Terminal. Discovery needs EMF, and the RemoteCDT integration needs CDT.
• If you use the dstore server, the protocol version number as well as the default daemon port were updated. You should use an RSE 2.0 dstore server with this build.
• See also the Official TM 2.0 New and Noteworthy for a summary of interesting changes since RSE 1.0.
• No API changes were made in this build. 9 bugs were resolved:
  • P1 bug 194442 to improve migration of dstore daemons to the 2.0 version
  • P1 bug 187301 to support multiple RSE shells with Telnet
  • P1 bug 192696 to fix a deadlock with RSE opening its perspective.
  • the other bugs were documentation-only fixes.
  Use this query to show the list of bugs fixed since the last milestone, TM 2.0RC4 [build notes].
• For details on checkins, see the RSE CVS changelog, and the TM Core CVS changelog.
• For other questions, please check the TM and RSE FAQ as well as the TM 2.0 Known Issues and Workarounds.

The RSE User Documentation now has a Tutorial that guides you through installation, first steps, connection setup and important tasks.

If you want to know more about future directions of the Target Management Project, developer documents, architecture or how to get involved,
the online Getting Started page as well as the TM and RSE FAQ are the best places for you to get started.

An important part of the Target Management 2.0 Project Plan is to harden the APIs which were provisional by RSE 1.0. Naturally, this requires API changes, and especially moving lots of classes which we cannot guarantee to support in the future into internal packages.

The list of breaking API changes is found below with migration info. See also the release notes as well as migration docs on the Wiki for more information.

Although we completed a great deal of API cleanup for TM 2.0, we decided to still mark all API as provisional since we expect more work to do. If anyhow possible, we will avoid breaking API changes after TM 2.0, but please be prepared for future changes, and especially take care of API marked as @deprecated in the Javadoc. Such API is prime candidate to be removed in the future. All API changes will be voted by committers on the dsdp-tm-dev developer mailing list, and documented in a migration guide for future releases. Early migration information can also be found right in the bug reports. Look for those that are tagged [api][breaking].

• TM 2.0 Breaking API Changes
  • None
• TM 2.0RC3 Breaking API Changes
  • ISystemResourceManager - removed two methods getRemoteSystemsProject() and getProfileFolder(String). The method getRemoteSystemsProject() was a convenience method that was equivalent to getRemoteSystemsProject(true) and it forced the creation of RemoteSystemConnections project in the workspace. This was undesirable given the current persistence provider defaults. The method getProfileFolder(String) returned a IFolder for a profile under the old persistence provider scheme. The method was obsolete and should not be being used at all. [191130]
  • The version number of the dstore server was updated from 8.0.0 to 9.0.0 - running this build against an older dstore server will likely work, but will receive an incompatibility message on connection. [188365]
• TM 2.0RC2 Breaking API Changes
  • Cleaned up ISystemRegistry and ISystemProfileManager - removed several convenience methods that are easily accessible through more common methods. If your code does not compile any more because it is missing methods in ISystemRegistry, browse RSE looking for alternative methods to do what you need [175680] [189749].
  • Removed FileSelectionDialog, SystemFilterTableDialog and related obsolete code. For migration, use SystemRemoteFileDialog instead [189973] [189508].
  • Removed icons, messages, constants and methods referring to User Actions. Since user actions are not shipped with TM 2.0, these items would not have been functional and have thus been removed. For migration, just remove corresponding usage of API in your code [186589].
  • Removed showActionBar() and showButtonBar() in ISystemViewInputProvider, and moved ISystemViewInputProvider to non-UI. Showing of action and button bars is now governed by the dialogs or views using a SystemView component. For migration, just "organize imports" and get rid of the deprecated methods in ISystemViewInputProvider [189506] [190271].
  • Moved the Terminal Telnet connector into a separate plugin [174162].
• TM 2.0RC1 Breaking API Changes
  • Created API for default encoding of a connection on the IHost level. Existing IRemoteCmdSubSystem.getEncoding() is to be replaced by IRemoteCmdSubSystem.getHost().getDefaultEncoding(true). For details, see bug [179937].
  • Moved RSESystemTypeAdapter.createNewHostInstance() to IRSESystemType.createNewHostInstance(). This was necessary in order to support moving SystemHostPool from UI to Core, which is a blocking prerequisite for future enhanced UI/Non-UI separation. Migration: Extenders of RSESystemTypeAdapter will need to change their code [176211].
  • ISystemRegistry.fireEvent() now switches to the Display thread automatically. This may be relevant for event listeners to know [176601].
  • Moved SystemIFileProperties from UI to Core, in preparation of moving SystemRegistry into non-UI in the future. For migration, just organize imports [189130].
  • Moved three methods from ISystemRegistry into ISystemRegistryUI in preparation of moving SystemRegistry into non-UI in the future: showRSEPerspective(), expandHost(), expandSubSystem() are now UI-only methods. Note that for non-UI expand, an event exists in ISystemResourceChangeEvents.EVENT_SELECT_EXPAND. Migration notes: use the methods from their new home. For details, see bug [189123].
  • Moved one method from ISubSystemConfigurationAdapter into ISubSystemConfiguration in preparation of moving SystemRegistry into non-UI in the future: renameSubSystemProfile(). Migration notes: use the method from its new home. Override renameSubSystemProfile() in its new home. For details, see bug [189123].
  • Renamed subsystemFactory to subsystemConfiguration in IActionFilter implementation of RSE model objects, which is being used in plugin.xml contributed popupMenu and propertyPage extensions [189163].
  • Renamed plugin org.eclipse.rse.eclipse.filesystem to org.eclipse.rse.efs.ui and org.eclipse.rse.efs respectively, in preparation of future UI/Non-UI split and making the name better understandable [188360] [186320].
• TM 2.0M7 Breaking API Changes
  • Moved some more classes, like the dstore miners, ISubSystemConfigurationAdapter, or Terminal API classes (which have been marked provisional). These changes can simply be picked up by running "organize imports" on client code [180649] [186748] [186134].
  • Moved the subsystemConfigurations and keystoreProviders extension points to org.eclipse.rse.core in order to better support UI/non-UI separation [186523] [186525].
  • Removed the remoteSystemsViewPreferencesActions and dynamicPopupMenuExtensions extension points since the same can now be achieved with standard org.eclipse.ui extension points [185552] [185554].
  • Fixed incorrect usage of IRSESystemType.getAdapter(). This change is important to consider manually since it does not break the build - see the bug entry for details [186779].
  • Made IRemoteFileSubSystem forward exceptions rather than handling itself by opening dialogs [183824].
  • Unify Singleton Access Methods to use getInstance() in most cases in order to achieve better API consistency [177523].
  • Added IProgressMonitor parameter to all long-running IRemoteFileSubSystem methods. Clients need to pass in a NullProgressMonitor in all these methods now. Moved the IProgressMonitor parameter last in all methods for consistency. [184322] [186128].
  • Use IRSESystemType instead of String systemTypeName everywhere - this is the prerequisite for allowing system type labels to be translated [180688].
  • Move SysteRegistry's Event Interface to non-UI and split ISystemRegistryUI from ISystemRegistry - See the bug entries for migration docs [168975] [186773].
  • Dont implement interfaces just for Constants - See the bug entry for migration docs [183165].
• TM 2.0M6a Breaking API Changes
  • Making more classes "internal": Lots of more packages and classes were tagged as discouraged access (moved to "internal"). For migration, just "Organize Imports" and search for alternative ways of doing things in case you end up with imports from "internal" packages. For details, see [170922].
  • Refactored IConnectorService and moved to Core for beter UI / Non-UI separation. Most notably, the concept of a CredentialsProvider was added. That work is not quite complete yet, but the bulk of the work has been done. For detailed migration info, see [168977].
  • Renamed getAdapter(Object) -> getViewAdapter(Object) on several classes. For migration, same renaming may need to be done in client code. [175150].
  • Dont implement constant interfaces just to bring constants into namespace. As an effect of this, some classes that clients can derive from do not "see" some constants any more. For migration, these constants will need to be qualified with the interface that they come from. For details, see [180562].
  • Streams are now part of IFileService and IRemoteFileSubSystem. Supporting Streams was important for the EFS integration and is a more modern and flexible way to download and upload. Thus Streams are now mandatory, and extenders must ensure that they implement getInputStream() and getOutputStrem() properly in their own file services and subsystems. [162954] and [179850].
  • IHost.getSystemType() now returns an IRSESystemType instead of a String. More similar changes will follow, in order to move from system type Strings to IDs and translatable / externalizable labels. For migration, client code can replace getSystemType() by getSystemType().getName(). [175262].
  • Support Menu Configuration in RSESystemTypeAdapter [161195].
  • The RSE Communications Daemon has been removed since it was never quite properly supported in Open Source [180602].
  • The org.eclipse.rse.logging plugin has been removed, functionality is now in the core and UI plugins, respectively [170920].
• TM 2.0M5 Breaking API Changes
  • Modified Extension Point subsystemConfigurations to reference system types by ID rather than by name. Client code needs to use the systemTypeIds tag now rather than systemTypes [162081].
  • Removed Extension Points for Popup Menus and Property Pages: The RSE-specific extension points org.eclipse.rse.ui.propertyPages and org.eclipse.rse.ui.popupMenus were removed because newer Eclipse versions have all required functionality in the base extension points already. Example code, tutorials and ISV docs were updated and have the required information for how to migrate to the new extension points. [172651].
  • Moved extension point org.eclipse.rse.ui.archiveHandlers to org.eclipse.rse.services.archiveHandlers [173871].
  • newConnectionWizards: The old newConnectionWizardDelegates extension point has been replaced by a new newConnectionWizards extension point for more flexibility [173772].
  • Deep Filtering: The SystemView now supports Context Information for queries of multiple filters to the same remote elements. That is, the SystemViewElementAdapter.getChildren() method can know the filer context in which a query is made. This is necessary in order to properly support "deep filtering" by file types. An API change was required to get this implemented: Existing code needs to change two method signatures in classes deriving from AbstractSystemViewAdapter. For details, see [170627].
  • Making classes internal: Many classes have been made internal, and PDE support for generating warnings of discourage access has been enabled. Client code should not have used the classes which are now internal anyways; but if you do, just running "organize imports" should make your code compile again. For details, see [170922].

No major or critical bugs are known at the time of release. Use this query for an up-to-date list of major or critical bugs.

The TM 2.0 Known Issues and Workarounds Wiki page gives an up-to-date list of the most frequent and obvious problems, and describes workarounds for them.
If you have other questions regarding TM or RSE, please check the TM and RSE FAQ

Click here for a complete up-to-date bugzilla status report, or here for a report on bugs fixed so far.