[sequoyah-dev] List of tasks for Pulsar SDK UI conversion

[<David.Dubrow@xxxxxxxxx>]

Title: List of tasks for Pulsar SDK UI conversion

Hi everyone,

This is my first pass at a list of development tasks to implement the P2 discovery UI for the Pulsar SDK install view. 

1. Metadata generator tool:

A very small change is required in metadata generator tool to allow us to use the very nice utility DiscoveryUi.install() to install catalog items returned from the catalog viewer directly rather than forcing the Pulsar code to gather the IUs from the items and install them. Basically, this utility expects IUs to have 2 aspects we currently don’t have in our generated metadata which is that the IUs need to be considered groups
 - the ids of the IUs must end with .feature.group and 
 - the ‘org.eclipse.equinox.p2.type.group’ property must be true 
The current metadata generator does not enforce this for Pulsar SDK features. I have tested with the metadata for the Nokia SDKs that this allows installation via the utility and is backward compatible with the Pulsar 1.0 SDK install view. Existing metadata can be hand modified and works in both environments.

2. The uninstall dialog:

As mentioned in the call and in my previous message, we need to migrate the uninstall functionality into a dialog. This probably could be very no-frills. We could use org.eclipse.ui.dialogs.ListDialog to present the list of installed SDKs and migrate the current uninstall code to uninstall the selected SDK. The action should not be enabled when there are no installed SDKs.

3. Replacing the current UI in the SDK install view with the P2 Discovery Catalog Viewer:

This task will replace much of the UI and core code with thin p2 discovery client code. We need to create a catalog with two discovery strategies. One will be a bundle discovery strategy to allow SDK vendors to test creating their discovery metadata plugin from an eclipse workspace without needing to deploy it to a server. The other will be a remote discovery strategy pointing to a discovery.xml file somewhere where it can be modified dynamically as needed with urls to SDK vendor metadata plugins. I have not tested whether we’ll need to filter by host OS or whether this is done by the catalog viewer. Some investigation will be needed to determine what if anything we may need to do to filter by host OS.

4. Testing... (including multiple OS testing – which does not apply to Nokia SDKs) :)
5. Documentation of requirements for SDK vendors and how to create the discovery metadata plugins and modify their existing content xml.

I believe this covers everything. Tasks 1 and 2 are very small and 3 should not be too much either. I think this will mostly be an exercise in removing code more than generating new code. :) I think this will take 1 or maybe 2 man-weeks at most, barring any unforeseen issues that may arise.

--David Dubrow