On this page:
Symptoms — What Goes Wrong
During plugin development, you encounter a
The exceptions are caused by the way classloaders work for plugins. With OSGi, every plugin needs to explicitly import every package it needs, otherwise the plugin's classloader will not have access to the package and will throw this exception.
If you do not specify your own package imports, the plugin framework 'guesses' which ones you need by scanning the class files in your plugin. Your plugin
.jar file is transformed at startup and placed in the directory
META-INF/MANIFEST.MF file in that transformed jar (not the original jar file) is where the package imports are ultimately specified using the header
Import-Package like this:
or for a more complex plugin:
Note that there is a line length restriction in jar files.
This header comes from the OSGi manifest specification, which defines extra headers that it needs to connect the JAR to other JARs or bundles. If you are familiar with OSGi, you can generate your own
Package-Import header, along with the other required headers. But most plugin developers will want the framework to handle that for them.
This technique works quite well for most simple plugins, but the more complex the plugin the greater chance of missing a required package.
In short, add an explicit
<Import-Package> element to the
plugin-info element in
The longer explanation is that the Atlassian Plugin Framework tries to determine which packages your plugin needs in order to generate the OSGi manifest headers for you. If this does not work, you likely need to customise the instruction used to scan your plugin.
You can do this by using the
<bundle-instructions> element in the
<plugin-info> element in your plugin's
atlassian-plugin.xml (not the
pom.xml).See Configuring the Plugin Descriptor.
In this example
atlassian-plugin.xml we force the scanning to include the
com.mylibrary package, in addition to its usual scanning:
Be sure to mark packages as optional imports where applicable.