As far as I know providing sun.* packages from the framework is the only
solution. I guess you can tweak the karaf feature validation to respect
these changed export. Probably you need to ask on the karaf list.
If bundles have broken OSGi data then it makes sense to help them with a PR
and maybe do your own release based on your fork for the mean time. You can
also check servicemix bundles. There you find working bundles for many jars
that otherwise cause problems in OSGi.
What you can also try is to use the wrap: protocol in karaf and override
some of the settings but generally I consider it bad practice if wrap is
2018-03-02 13:29 GMT+01:00 Cristian Târşoagă via osgi-dev <
> I try to use OSGi in my own module.
> I use maven and I plan to deploy under apache karaf.
> The dependency tree for my own module is quite large, and I quickly ran
> into troubles while trying to create a feature.xml descriptor, to provision
> the karaf container will all the required modules.
> I hit at least 3 different issues with jars that are *dependencies* for me
> (so not under my control)
> 1. Some dependencies require sun.nio.ch, or sun.security.util packages,
> which I think are *private packages*, so they should not be used.
> Checking my feature.xml results in errors, since it cannot use those
> private packages.
> I saw a workaround for this but at runtime, someone suggested enabling
> those packages from the container, so I guess that if I could ignore the
> feature validation, at runtime, on certain platform, I could use the
> dependency - still, this is not a clean solution while I'm validating the
> feature.xml descriptor
> Another workaround is to mark the import as optional, but I cannot do that
> myself, it's part of the external dependency.
> 2.Some dependencies have some OSGi entries, but are *missing
> Which makes them unusable.
> 3. Some other dependencies are having bad OSGi entries in their manifests,
> e.g. require a fixed version for jvm, e.g.
> Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(
> I was not able yet to figure out a clean solution for these 3, in the
> 'client-side', meaning in my own module, while using the dependencies.
> Unless I contribute myself to these external projects and fix the
> manifests. (which is ok, but requires more time)
> Is there some clean solution to these, at least to some extent? Am I
> missing something?
> Can someone point to some workarounds for 1), 2), 3) that I could apply
> without modifying the dependencies?
> Thanks a lot
> OSGi Developer Mail List
OSGi Developer Mail List