diff --git a/releng/org.eclipse.rse.build/template/buildNotes.php b/releng/org.eclipse.rse.build/template/buildNotes.php index 3ce9d324926..a899e56657c 100755 --- a/releng/org.eclipse.rse.build/template/buildNotes.php +++ b/releng/org.eclipse.rse.build/template/buildNotes.php @@ -52,14 +52,44 @@
    -
  • The subsystemConfiguration extension point has been renamed to - +
  • Renamed the org.eclipse.rse.ui.subsystemConfiguration extension point + to subsystemConfigurations in order to better match the standard naming scheme used by the Platform.
  • -
  • The newConnectionWizardDelegate extension point has been renamed to - +
  • Renamed the org.eclipse.rse.ui.newConnectionWizardDelegate extension point + to newConnectionWizardDelegates in order to better match the standard naming scheme used by the Platform.
  • +
  • Removed the org.eclipse.rse.ui.rseConfigDefaults extension point. + Use Java Properties instead, as described in the documentation.
  • +
  • Removed the org.eclipse.rse.ui.passwordPersistence extension point. + The same functionality is achieved by using the data known from the + subsystemConfigurations extension point.
  • +
  • Moved several RSE Model Objects and Interfaces from org.eclipse.rse.ui to core: +
      +
    • (UI) org.eclipse.rse.model --> org.eclipse.rse.core.model
    • +
    • (UI) org.eclipse.rse.filters --> org.eclipse.rse.core.filters
    • +
    • (UI) org.eclipse.rse.subsystems.servicesubsystem --> org.eclipse.rse.core.subsystems
    • +
    + Client code can be adapted to the new locations easily by invoking "Organize Imports" except for + the following additional changes that need to be made: +
      +
    • Event handling methods for ISystemResourceChangeEvent, + ISystemPreferenceChangeEvent, + ISystemModelChangeEvent, + ISystemRemoteChangeEvent have been removed from + ISystemRegistry, such that they are available only in the + SystemRegistry implementation. This applies to the fireEvent(), + postEvent() and corresponding add...Listener() methods. The simplest + fix in user code is to get the SystemRegistry from RSEUIPlugin + instead of SystemRegistry as described below.
    • +
    • Use RSEUIPlugin.getTheSystemRegistry() instead of SystemRegistry.getSystemRegistry()
    • +
    + Note that wherever possible, client code should only refer to the model object + interfaces in org.eclipse.rse.core.* and not use the actual + implementations which still reside in the UI plugin (these will be moved + to core eventually, too). +
@@ -98,7 +128,7 @@ be informed in case the APIs should change.

local subsystems (these do not define any new APIs anyways).
  • The IConnectorService interface may be slightly modified in order to allow for better UI / Non-UI separation.
  • -
  • Some RSE Model classes may be moved from the UI plugin to the +
  • Some more RSE Model classes may be moved from the UI plugin to the non-UI core plugin.
  • If you want to start programming against RSE APIs now, best let us know @@ -134,11 +164,7 @@ deliverables did not make it into this build: The following critical or major bugs are currently known. We'll strive to fix these as soon as possible. Click here diff --git a/rse/doc/org.eclipse.rse.doc.isv/guide/Artifacts.html b/rse/doc/org.eclipse.rse.doc.isv/guide/Artifacts.html index 85967ef230b..dac67350e4b 100755 --- a/rse/doc/org.eclipse.rse.doc.isv/guide/Artifacts.html +++ b/rse/doc/org.eclipse.rse.doc.isv/guide/Artifacts.html @@ -136,7 +136,7 @@ in your own subsystem's ISystemFilter +A filter is simply a ISystemFilter object containing a name and a collection of filter strings. Filter strings are just strings, which the subsystem is required to interpret. When a user expands a filter, the owning subsystem is asked to resolve the filter strings within the filter. The subsystem typically interprets each filter string as some form of @@ -155,12 +155,12 @@ It is possible to author a subsystem that does not support filters, if this is d Subsystems do not actually "own" filters. Since each host has unique subsystems, if each subsystem owned its own filters then filters could not be shared across Hosts, which is sometimes desirable. Instead, filters are actually contained within filter pools. Filter pools are simply -ISystemFilterPool +ISystemFilterPool objects which have a name and a collection of filters. Filter pools are owned by subsystem configurations, per profile. That is, each subsystem configuration will contain filter pools scoped by profile. Each such configuration plus profile grouping is known internally as a -filter pool manager. -Subsystems contain references +filter pool manager. +Subsystems contain references to filter pools. By default, each subsystem configuration automatically creates one filter pool for each profile, named the "xxx Filter Pool", where "xxx" is the name of the profile. Subsystems contain references to filter pools, so that as the filters in the pool are created, changed, deleted or re-ordered, those changes are automatically @@ -198,7 +198,7 @@ be exported and imported.

    System Registry

    The programmatic front door to all the artifacts in the RSE is the System Registry, which is an object implementing -ISystemRegistry. +ISystemRegistry. This is a singleton object that you can access by calling the static method getSystemRegistry() in the diff --git a/rse/doc/org.eclipse.rse.doc.isv/guide/Model.html b/rse/doc/org.eclipse.rse.doc.isv/guide/Model.html index 0defa67769c..4fd3de51c33 100755 --- a/rse/doc/org.eclipse.rse.doc.isv/guide/Model.html +++ b/rse/doc/org.eclipse.rse.doc.isv/guide/Model.html @@ -16,20 +16,20 @@

    At runtime, the model takes a slightly different form: