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: -->
<!-- https://developer.atlassian.com/docs/advanced-topics/configuration-of-instructions-in-atlassian-plugins -->
<instructions>
	<Atlassian-Plugin-Key>${atlassian.plugin.key}</Atlassian-Plugin-Key>

	<!-- Add package to export here -->
	<Export-Package>
		com.ferencnagy.api,
	</Export-Package>

	<!-- Add package import here -->
	<Import-Package>
		org.springframework.osgi.*;resolution:="optional",
		org.eclipse.gemini.blueprint.*;resolution:="optional",
		*
	</Import-Package>

	<!-- Ensure plugin is spring powered -->
	<Spring-Context>*</Spring-Context>
</instructions>

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?

Regards,
Ferenc

Hi,

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: Bitbucket

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.

Cheers,
Bernhard

3 Likes

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.

6 Likes

Hi @ferenc.nagy,

It’s been a long time since I developed against server so I won’t be able to provide much useful advice. However, I am intrigued by the statement “so I tried to remove the above section to avoid the OBR generaton”:

What is your motivation to stop generating the OBR file - is this efficiency, improved security, ??? Also, is there some Atlassian documentation suggesting this section can be removed? I suspect OBR generation is fairly deeply coupled into the plugin system so maybe it’s not feasible.

The following link has some useful information on OBR files if you haven’t already seen it.

https://developer.atlassian.com/server/framework/atlassian-sdk/bundling-extra-dependencies-in-an-obr/

Regards,
Dugald

1 Like

Hi @dmorrow,

Thanks for your comment!

We have some other, older apps where the app components are defined in the “atlassian-plugin.xml”, not using the more modern Spring scanner technique.
https://developer.atlassian.com/server/framework/atlassian-sdk/spring-java-config/

When those apps are built with the “atlas-package”, only a JAR file is created (no OBR).

Our new app is based on this sample app, which uses Spring scanner for component config.
https://bitbucket.org/atlassian/automation-addon-sample/src/master/automation-thirdparty-sample/

When this app is built, the OBR file is generated, however we don’t want to add dependency on any other app. That’s why I was wondering if it’s possible to exclude the OBR generation and have the JAR file only. Actually, when the JAR is uploaded to Jira, everything works fine and we are planning to distribute that in the Marketplace.

What do you think about this?

Regards,
Ferenc

1 Like

Hi Ferenc,

AMPS maintainer here. Thanks for your question.

If you have an instructions section in your POM, which you typically need in order for your plugin to load, AMPS will generate both an OBR and a JAR. If you don’t need the OBR, i.e. you don’t need to bundle any other plugins, you can simply ignore it.

We could conceivably add a flag to AMPS to allow the OBR generation to be skipped, but given that generating the OBR is not an expensive operation, it doesn’t seem as worthwhile as some other things on our backlog.

Cheers,

Andrew

4 Likes

Hi @aswan,

Thanks for clarifying this, I really appreciate it!

Regards,
Ferenc

1 Like