Packaging app to JAR vs. OBR

Hi Community,

We are developing a Jira server app and after creating the code skeleton with “atlas-create-jira-plugin”, the following section is added to the “jira-maven-plugin” in the “pom.xml”:

<!-- See here for an explanation of default instructions: -->
<!-- -->

	<!-- Add package to export here -->

	<!-- Add package import here -->

	<!-- Ensure plugin is spring powered -->

As the result of this, beside the JAR file, an OBR file is also generated after the build. In the OBR, the “dependencies” folder is empty, which is expected as we don’t want to include any other JAR there.

The app seems to work fine when the JAR is installed into Jira, so I tried to remove the above section to avoid the OBR generaton, but that leads to different class loading issues.

Could someone explain what is really going on here? Also, do we need to leave the section above in the “pom.xml”, but upload the JAR to the Atlassian Marketplace, or should we use the OBR file?



I am not from atlassian, but had this some time ago as well.
Atlassian told me this gemeni blueprint stuff is outdated. I also complained, that the create-app thing does not generate the latest version of app scaffolding.

It is important to use SpringScanner v2 and this includes many small changes, all explained here:

And you should only export stuff that you want to use from another app. For example if you use ScriptRunner then you could use the API you export via com.ferencnagy.api inside your ScriptRunner scripts. But if you want your app to be “isolated” just export a dummy package with empty Interface.

I upload the JAR to the marketplace. I think you can use either OBR or JAR.



Just to provide some additional info:

AFAIK, the instructions section is related to OSGI, which needs this information. Together with the atlassian-scanner stuff @clouless mentioned, it tells OSGI which packages that other bundles (such as Jira) expose to inject into your bundle. You can find the resulting file (after the spring-scanner does its thing) in the JAR file in META-INF/MANIFEST.MF.

If, when you try to enable your app, Jira complains about some classes not being found, it’s worth trying to check your annotations. In some cases, it might be required to manually add the classes to the Import-Package section. But that’s rarely the case.

If you do have multiple apps that access each other’s content, or if you want to run Arquillian tests, the Export-Package sections gets interesting.

That first one is also the use case for OBR files: If you bundle your app into multiple OSGI packages (JAR files), then you need the OBR file. It’s basically a container for multiple JARs. This can be useful if you have shared functionality between apps or if you have different libraries that insist on bringing their own versions of dependencies that clash with each other.

Try to avoid that in general though, especially if you want to distribute your app on the Marketplace, since this technique creates multiple app entries in UPM that might confuse customers and it’s annoying to deal with when en/disabling, un/installing and sometimes even updating.