Alternate deployment model for licensed plugins
It is possible that your plugin will fail to start if the Licensing API (either License Storage plugin or UPM 2.x+) is not present at the time of your plugin's installation.
What was supposed to happen?
If you followed the licensing tutorial, you should have the following component in your
component, when initialized, installs and/or enables the License Storage plugin (if needed) that supports your plugin's licensing. The License Storage plugin allows your plugin to have the Licensing API available always, even for older product versions that do not come bundled with UPM 2.0.
What went wrong?
Some plugins have components that use the Licensing API and get initialized before the
PluginLicenseStoragePluginInstaller component has a chance to initialize. When this occurs, the first component (the one that uses the Licensing API) fails to initialize. It fails because it cannot resolve the Licensing API's classes, and as a result, the plugin fails to start up—all before
PluginLicenseStoragePluginInstaller has a chance to complete.
To determine whether or not your plugin has this problem, remove the following
How do I work around this problem?
You can deploy your plugin as an OBR (OSGi Bundle Repository) file with the License Storage plugin provided as a dependency.
- Bump your
upm.license.compatibility.versionproperty to 2.2.2 or later.
Add the following
pluginDependenciessection to your
Delete the following four packages from your
<DynamicImport-Package>tag. If these are the only four packages listed as dynamic import packages, you should remove the entire
If you specify
<Import-Package>statements, you should add these four packages there.
- After rebuilding your plugin, distribute the
<artifactId>-<versionId>.obrartifact instead of the
You can verify the fix by starting up a fresh host product instance (without the License Storage plugin or UPM 2.x+ being installed). Then install your generated
.obr artifact in the Universal Plugin Manager.