[dtp-pmc] Re: [dtp-dev] Removing org.eclipse.ui Dependency from Base Con

[rcernich@xxxxxxxxxx]

> The following dependencies remain:
>    The property change notification mechanism still uses
>    org.eclipse.ui.IPropertyListener.  I'm currently working on a new
>    property notification mechanism.
>
>    The connect and disconnect code still relies on
org.eclipse.swt.Display.
>    This dependency can be removed but may have consequences when
>    integrating third-party plugins.  The current code keeps the message
>    loop running while the connections are being created.  This allows the
>    connect() and disconnect() methods to block without needing to worry
>    about whether or not connection factories use Display.syncExec()
This
>    is also used to help prevent deadlocks when connect() and disconnect()
>    are called in rapid succession (as jobs used to update the DSE may not
>    have executed prior to the subsequent call).  I think I can safely
work
>    around the DSE refresh problem, but would like some input as to
whether
>    this seems acceptable or whether the blocking versions of these
methods
>    should be removed entirely (i.e. leave it up to the caller to block
>    appropriately; perhaps providing a utility method in
...connectivity.ui
>    which duplicates this functionality).
>

I have addressed these remaining issues.  Attached is a patch file with the
complete changes.
(See attached file: headless_connectivity2.patch)

Here is a summary of the remaining API changes:
   org.eclipse.datatools.connectivity.IConnectionProfile
      removed add/removePropertyListener() methods.
      removed PROP_* constant fields
      added new property related fields
      added add/removePropertySetListener() methods.
   added org.eclipse.datatools.connectivity.IPropertySetListener
   added org.eclipse.datatools.connectivity.IPropertySetChangeEvent

The Display related code which was intended to prevent deadlock on the UI
thread, has been replaced with a call to IJobManager.cancel() using the
connection profile as the job family.  This should prevent deadlocks that
were associated with the RefreshProfileJob's.

Please let me know if you have any questions, comments, concerns, etc.

Thanks,
Rob

Attachment: headless_connectivity2.patch
Description: Binary data