cmj.spi.version to the lowest possible version of the SPI - for example, 1.0.0.
Increment the version when you need new features of the SPI. This will ensure compatibility with a large set of Configuration Manager releases, as older releases come with an older version of the SPI. There is no need to compile to a newer version unless you need some new features, as the SPI is backward compatible.
Make sure that DynamicImport-Package is used instead of Import-Package. Otherwise, the SPI-related packages may not be correctly resolved at runtime.
If building with Atlassian SDK 8.0.0+, you also need to add the instruction “!com.botronsoft.cmj.spi.*” to Import-Package.
Step 2: Implement app-specific SPI endpoints
Next, implement the SPI Endpoints from the list below for the types of configurations your app includes. For example, if your app deals with workflows or modifying workflows in Jira, you will need to implement the Workflows SPI Endpoints.
Server SPI Endpoints
Custom fields with specific configuration provided by the app.
App data which is not attached to a Jira object (project, custom field, workflow, etc.). Use this endpoint when the app data does not fit any of the boundaries of existing Jira objects and extend standard Jira functions.
Using this endpoint, you can enumerate the types of app data that can be migrated and the different objects of each type that exist on the Jira instance.
Listeners, which are “listening” for a specific event and triggering an action, and,
Behaviors customizing how fields “behave” based on the context, etc.
This type of app functionality is not categorized and guided by the Jira application development platform. Yet, the App Data SPI endpoint provides the tools to move such configuration between different Jira instances.