Pulsar is a mobile application platform based on Eclipse. It provides an easy mechanism to find mobile SDK and to install them in the developers local machine.
The objective of this document is to describe in detail the technical requirements that a SDK Provider need to fullfill in order to be integrated into Pulsar Server. Those requirements are broken in two categories: mandatory and optional.
- SDK: A SDK emulate a mobile device and provides a protocol that can be used by an eclipse extension to run a mobile application on it.
- SDK Provider: A SDK provider is an entity that will distribute a SDK to developers.
The SDK Provider must provide a p2 enabled repository
REQ1.2: Local SDK Provider Information
The SDK provider must provide send the following information to the Pulsar team, since this information is hardcoded into Pulsar. This can be done via email through Pulsar list.
- <provider-name>.metadata=<provider metadata repository>
- <provider-name>.artifacts=<provider artifacts repository>
- <provider-name>.name=<provider repository name>
The above information is used by Quickinstall feature to query and list those SDKs to the user. Since all of this information is is hardcoded, it can only be updated in a new Pulsar release.
REQ1.3: SDK Provider Repository Name
The repository name must be <SDK Provider Name> Repository.
REQ1.4: SDK Provider Metadata Repository
The SDK provider metadata repository must include the following property on the SDK installable unit org.eclipse.pulsar.type. The following values are accepted:
- ziparchive: sdk is deployed as a zip file that is unzipped on th users machine
- executable: sdk is deployed as an executable file that is unzipped on the users machine
- ziparchive: sdk is deployed as executable zipped file that is unzipped and then executed on the users local machine
- osgi-bundle: sdk is deployed as features and plugins that are installed on Pulsar Eclipse product
REQ1.5: Host Dependencies
The SDK feature must indicate its host dependencies based on eclipse standards (host, windowing toolit and architecture). For example if one specific SDK is only available on windows, its must featured must be filtered to win,win,x86. If this dependency is not indicated, the SDK will always be shown.
REQ1.6: Software Dependencies
Features and plugins available on the SDK provider must depend only on other features / plugins that are available on the Eclipse servers (External dependencies must be avoided). For instance, a SDK provider plugin can depend on a JDT plugin, but is must not depend on a plugin that is hosted on sourceforge.
REQ1.7: SDK License
The SDK installable unit must be configured with the correct SDK Provider license. This license will be shown to the user during the install process.
REQ2.1: SDK Provider Repository Information (Local)
The server layout might optionally include additional information that will be shown on the QuickInstall View. The possible properties are listed below:
- <provider-name>.image=: link to provider icon (16 x 16 gif file);
- <provider-name>.info.image= link to provider banner. 350 x 50 PNG or GIF file;
- <provider-name>.info.url= link to provider developer web site
- <provider-name>.info.description= description of the provider
The above information is hardcoded into Pulsar. The SDK Provider needs to send this information to Pulsar team. this can be done via email through Pulsar list. Since all of this information is is hardcoded, it can only be updated in a new Pulsar release.
REQ2.2: SDK Provider Metadata Information (Remote)
The SDK provider metadata repository might provide some additional information that is used by the QuickInstall view. The possible properties are listed below:
- org.eclipse.pulsar.category.name: The SDK Provider might group their SDKs into categories. For instance: Serie 40 SDKs, Serie 60 SDKs, etc.
- org.eclipse.equinox.p2.description: SDK description that is presented to the user when he selects the SDK
- org.eclipse.pulsar.documentation.url: list to the SDK documentation
The above information must be configured on the installable unit associated to the SDK itself. Since all of this information is always queried remotely, the SDK provider is free to change it whenever he wants.