[dtp-pmc] Removing org.eclipse.ui Dependency from Base Connectivity

[rcernich@xxxxxxxxxx]

Hey all,

Here's an update on the removal of the org.eclipse.ui dependency from the
base connectivity plugin.

The following patch will remove a majority of the remaining dependencies.
(See attached file: headless_connectivity.patch)

  Here are the API changes associated with this patch:
   org.eclipse.datatools.connectivity.IConnectionProfileProvider
      replaced Image getIcon() with URL getIconURL()

   removed
   org.eclipse.datatools.connectivity.operations.CreateProfileOperation
   (this was unused).

   moved org.eclipse.datatools.connectivity.IProfileWizardProvider to
   org.eclipse.datatools.connectivity.ui.wizards.IProfileWizardProvider

   moved org.eclipse.datatools.connectivity.IWizardCategoryProvider to
   org.eclipse.datatools.connectivity.ui.wizards.IWizardCategoryProvider

   added org.eclipse.datatools.connectivity.ui.ProfileImageRegistry

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 plan on committing these changes in the next day or two.

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

Thanks,
Rob

Attachment: headless_connectivity.patch
Description: Binary data