Not sure I understand the issue completely but it sounds like you have a hidden dependency on something. The way I typically try to handle this is to add a mandatory attribute for the hidden dependency version to the package so that importers must specify the correct value there. Again, this may or may not make sense in your case.
regards, Karl On Wed, Jun 16, 2010 at 4:04 PM, Justin Edelson <[email protected]> wrote: > On 6/16/10 3:33 AM, Felix Meschberger wrote: >> Hi, >> >> On 15.06.2010 23:22, Justin Edelson wrote: >>> >>> One thing that might work is to define a synthetic package representing the >>> front-end environment. But this would be versioned independently from the >>> Java package(s) the bundle exports. I'm just not sure how BND behaves when >>> you tell it to include an Export-Package header for a package which doesn't >>> exist. >> >> Interesting approach. I quickly tested exporting the res.lib package, >> which is the res/lib folder containing the JQuery libraries. This works >> perfectly. >> >> So, we could move the JQuery libraries to a new package, say >> org.apache.felix.webconsole.js, and export this package. Whenever we >> upgrade one of the libraries, we could increase the export version there. >> >> Consuming bundles could import that package and be sure to correctly >> wire; if they wished. >> >> WDYT ? > The problem with this approach is that you're exporting these resources > via the OSGi framework unnecessarily. Other bundles don't actually need > to do > ClassLoader.getResource("/org/apache/felix/webconsole/js/jquery.js"). > This isn't THAT big of a deal, but it is a leak. > > Nonetheless, I think this is the best you can do with the tools we have. > > Perhaps we should move this discussion to osgi-dev? > > Justin > >> >> Regards >> Felix >> > -- Karl Pauls [email protected]
