Skip to content

Add capabilities to Skija libraries to enforce loading fragment#62

Closed
HeikoKlare wants to merge 1 commit into
eclipse-orbit:mainfrom
HeikoKlare:skija-native-capability
Closed

Add capabilities to Skija libraries to enforce loading fragment#62
HeikoKlare wants to merge 1 commit into
eclipse-orbit:mainfrom
HeikoKlare:skija-native-capability

Conversation

@HeikoKlare
Copy link
Copy Markdown

Skija libraries are split into the skija-shared host and the actual native libraries for adopting Skia wrapped into fragments. Those fragments currently need to be explicitly pulled into an OSGi environment to make use of Skija, as the skija-shared library effectly depends on the presence of either of the fragments with the native libraries.

This change adds OSGi capabilities to the Skija libraries, such that the skija-shared host always requires one of the fragments to be present. This leads to the fitting fragment for the current platform automatically being pulled into a launch if available.

I am not sure how such a capability should be defined best, and I am also not sure if such a dependency between fragment and host may in any way be problematic. I locally patched the bundles/fragments in my bundle pool with these changes and the SWT Skia prototype with its tests (see eclipse-platform/eclipse.platform.swt#3231) worked fine then. See also eclipse-platform/eclipse.platform.swt#3231 (comment) for some context of this change as probably required for the SWT Skia adoption.

Skija fragment contain the actual native libraries for adopting Skia.
Those fragments currently need to be explicitly pulled into an OSGi
environment to make use of Skija, as the skija-shared library effectly
depends on the presence of either of the fragments with the native
libraries.

This change adds OSGi capabilities to the Skija libraries, such that the
skija-shared host always requires one of the fragments to be present.
This leads to the fitting fragment for the current platform
automatically being pulled into a launch if available.
@merks
Copy link
Copy Markdown
Contributor

merks commented May 20, 2026

I'm not 100% sure how this is supposed to actually work. The host requires capability whatever and each native fragment provides the same capability whatever. What ensures that only one fragment is picked up and that it's the fragment for the current native os/arch? The Eclipse-PlatformFilte` filter I guess? I need to test that...

@HeikoKlare
Copy link
Copy Markdown
Author

Exactly. I should have posted the description from the SWT use case here as well instead of just referring to eclipse-platform/eclipse.platform.swt#3231 (comment):

We want to express that when launching something with a dependency to skija-shared, a fitting native fragment must be present and loaded as well. The "fitting" aspect is already covered by the Platform-Filter. The "must be present" aspect is missing. This is something we can express with OSGi capabilities. I've locally added a Require-Capability to the skija-shared host bundle and a Provide-Capability to the fragment, and then the matching fragment is automatically picked for a launch.

merks added a commit that referenced this pull request May 20, 2026
- The MavenBND.target needs an additional excluded dependency to provide
the Require-Capability during the BND build.

#62
@merks
Copy link
Copy Markdown
Contributor

merks commented May 20, 2026

Closing in favor of the enhanced details of the other PR.

@merks merks closed this May 20, 2026
@HeikoKlare HeikoKlare deleted the skija-native-capability branch May 20, 2026 08:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants