We are developing a custom Confluence Data Center plugin that converts Confluence pages to DOCX format for Word export functionality( especially .doc to .docx ). During development, we encountered some questions regarding OSGi dependency management that we’d like clarification on.
Environment
Plugin built targeting: Confluence 8.2.1 Data Center
Actual running instance (dev): Confluence 8.5.19 Data Center
Production instance: Confluence 8.2.1 Data Center
Build tool: Atlassian SDK (atlas-package)
Build JDK: 11
Libraries Used
The following libraries are used in our plugin for HTML-to-DOCX conversion:
LibraryVersionPOM ScopeUsageapache POI (poi, poi-ooxml, poi-ooxml-schemas)4.1.2compileDOCX generation via XWPFDocumentxmlbeans3.1.0compileRequired by poi-ooxml-schemasjsoup1.14.3providedHTML parsingcommons-codec1.14providedBase64 decodingcommons-collections44.4providedRequired by POI internallybatik-transcoder / batik-codec1.16providedSVG to PNG conversion
What We Observed
When inspecting the OSGi Browser on both instances:
POI / xmlbeans / openxmlformats
Not exported by System Bundle on either instance. Declared as compile scope, physically bundled inside plugin JAR.
jsoup
Exported by System Bundle as 1.14.3 on production (8.2.1) and 1.15.4 on dev (8.5.19). Also physically bundled inside plugin JAR after atlas-package. Since declared as resolution:=optional, System Bundle version takes precedence - meaning the plugin runs against different jsoup versions between dev and production. Is this a problem?
commons-codec
Exported as 1.14.0 on production (8.2.1) and 1.15.0 on dev (8.5.19). Same situation as jsoup. Is this a problem?
commons-collections4
Exported as 4.4.0 on both instances. Same version on both. Is there anything we should be aware of?
batik
Confirmed present in System Bundle on both instances. Declared as provided with resolution:=optional. Is this the correct way to use batik in a Confluence DC plugin, and are there any known issues with batik 1.16 on Confluence 8.2.1?
Questions
When using atlas-package with atlassian-plugin packaging, is it expected behavior that provided scope dependencies are physically bundled into the plugin JAR? If so, what is the recommended way to prevent this?
Given that our plugin is built targeting Confluence 8.2.1 but tested on Confluence 8.5.19, are there any known breaking changes between these versions that could affect the libraries we are using, particularly around OSGi package exports from the System Bundle?
When both the System Bundle and the plugin JAR contain the same package (e.g., jsoup), and the import is declared as resolution:=optional, is it guaranteed that the System Bundle version always takes precedence? Or does this depend on OSGi wiring order?
Is there an official list of packages exported by the System Bundle for Confluence 8.2.1 Data Center, so we can properly determine which dependencies should be provided vs compile?
Regarding batik-transcoder 1.16 declared as provided - is this library included in the System Bundle of Confluence 8.2.1 Data Center? If not, what is the recommended approach for bundling it safely without conflicts?
Thank you for your time. Any guidance on properly structuring OSGi dependencies for Confluence Data Center plugin development would be greatly appreciated.