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 Export-Package*
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)(*version=1.8.0_144*

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

Reply via email to