Hi, On Mon, Sep 21, 2015 at 6:03 PM, Steven Walters <[email protected]> wrote: > > upload guava-17.0.jar to /apps/a/install/guava-17.0.jar > This creates a new bundle registered within Felix. > > upload guava-18.0.jar to /apps/b/install/guava-18.0.jar > This updates the 17.0 bundle in felix to be the 18 version.
Well, TBH, I see this as a problem with Guava. I understand their versioning scheme for releases, but it does not make sense for OSGi package exports. Basically they're saying 'each release breaks everything'. I would rather see them properly version the exported packages. There an issue about this at https://github.com/google/guava/issues/1682 so please add your comment if you think this is important. And also note that while OSGi allows you to deploy multiple versions of a bundle ( or rather export the same with different versions ) this isn't a perfect solution. There are limitations imposed by the Java runtime, including the fact that you can't have multiple definitions of a class inside available to the same consumer ( aka consistent class spaces ). Consider the following scenario: [Bundle B1] -> [Guava 17] [Bundle B2] -> [Guava 18] [Bundle C1] -> [Bundle B1, Bundle B2] At this point Bundle C1 is potentially exposed to multiple versions of Guava and Felix will complain about a uses constraint violation. As an interim solution, if the bundles would be under my control I would use Require-Bundle for the Guava imports. Yes, it's ugly and not recommended, but then again we're not in a standard situation. If the bundles are not under my control I would keep Guava 18 and deploy a custom bundle which wraps Guava 17 and has a different Bundle-SymbolicName. This allows both bundles to be deployed and wirings to succeed. HTH, Robert
