Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>In addition to Filippo's solution, you can try to invert the dependency. F.i. instead of calling and inspecting the other bundles, you can let the bundles do that. Another way would be using a bundle tracker and obtaining the ClassLoader of the Bundle tracked. With this class loader you can act "as the bundle", so you don't need the Import-Package clause anymore. </p> <p>When I started using OSGi, this was one of the first requirements I came up. Over time, I realized that in almost all cases, there is a cleaner and more consistent solution. So, think about it, if you really need this dependency. Is there no way to invert or abstract it to create a generic solution? </p> <p>If nothing helps (as a last resort), you can also create (in Memory) a fragment with your core bundle as host, providing the required imports. The BundleContext offers you a method to load a bundle from a stream. You then have to update and call refreshpackages(via PackageAdmin service) on your host bundle in order to get the updated ClassLoader (implies a restart of your bundle). However, at the end, you'll have access to all your packages. </p> <p>As a side note, I would not recommend to manipulate your host bundle by tweaking the import statement and then update... This renders your bundle indeterministic and won't work with signed bundles. Also, this is against everything one expects from OSGi (imagine a growing bundle over time... you need to shrink the imports at some point as well!!!)</p> <p>Cheers, Mirko</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload