# Fixing (known) OSGi metadata problems when installing bundle **URL:** \ **Category:** GENERAL\ **Created:** [January 15, 2021, 11:59pm UTC](https://bnd.discourse.group/t/fixing-known-osgi-metadata-problems-when-installing-bundle/75 "2021-01-15T23:59:28Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![chrisr3](https://yyz2.discourse-cdn.com/free1/user_avatar/bnd.discourse.group/chrisr3/32/58_2.png) [@chrisr3](https://bnd.discourse.group/u/chrisr3)\ **Post date:** [January 15, 2021, 11:59pm UTC](https://bnd.discourse.group/t/fixing-known-osgi-metadata-problems-when-installing-bundle/75/1 "2021-01-15T23:59:28Z")
I am starting to see what people mean about a lot of OSGi metadata being broken! Today I discovered a bundle `FOO` which depends on both Guava [29, 30) and `BAR`, where `BAR` also has an _optional_ dependency on Guava [17, 18). Gradle silently resolves Guava 17 to Guava 29 anyway, and this doesn’t matter until we then add `FOO` to an OSGi framework and use the particular the package from `BAR` that triggers its `optional` Guava dependency. At this point, the framework gives up and throws an exception because no single version of Guava can satisfy both requirements. Do people _routinely_ rewrite OSGi metadata for 3rd party bundles please? This seems like a terrible burden, and each one requires us to add new dependency substitution rules to our `build.gradle` scripts too. In this particular case, we’d only need to tweak `BAR` to require Guava [17, 30) instead of Guava [17, 18). This _seems_ like something we might be able to do when installing bundle `BAR` instead - perhaps via some kind of `BundleListener`? Does OSGi or Bnd have any existing capacity for applying metadata “errata” please? (User-supplied, user specific and hand-written, of course. It would almost certainly need human involvement.) Thanks for any advice here, Cheers, Chris ---
**Author:** ![pkriens](https://yyz2.discourse-cdn.com/free1/user_avatar/bnd.discourse.group/pkriens/32/3_2.png) [@pkriens](https://bnd.discourse.group/u/pkriens)\ **Post date:** [January 16, 2021, 2:02pm UTC](https://bnd.discourse.group/t/fixing-known-osgi-metadata-problems-when-installing-bundle/75/2 "2021-01-16T14:02:55Z")
> [@chrisr3](#): > > Do people _routinely_ rewrite OSGi metadata for 3rd party bundles please? This seems like a terrible burden, and each one requires us to add new dependency substitution rules to our `build.gradle` scripts too. No, I rarely _wrap_ bundles. However, I have two very well working strategies. First, minimized dependencies. Yes, Guava has some nice classes but since Java 8 you find most of them in the VM already. And if there is this cool feature in a library, I have no qualms copying the source code if the license permits. Since the root problem is _transitive_ dependencies, reducing dependencies in your project tends to have an exponential reduction in overall dependencies, mitigating the problem of bad metadata. A few years ago I helped someone with some OSGi issues. It turned out that he had 40Mb of dependency JARs to save about 1 line of code. By being very focused on minimizing dependencies, you can reduce most of the problems. Second, the key for OSGi development is _services_. Since many open source libraries suck in this respect, I just include these libraries in my own JAR and put an elegant service interface on them. Nobody cares about metadata of the private packages in your bundle. With `-conditionalpackage` you can even pick out only the parts that you need. ---
**Author:** ![chrisr3](https://yyz2.discourse-cdn.com/free1/user_avatar/bnd.discourse.group/chrisr3/32/58_2.png) [@chrisr3](https://bnd.discourse.group/u/chrisr3)\ **Post date:** [January 18, 2021, 10:05am UTC](https://bnd.discourse.group/t/fixing-known-osgi-metadata-problems-when-installing-bundle/75/3 "2021-01-18T10:05:23Z")
Hi, thanks for replying. The `FOO` jar is providing some common serializers for general use, some of which are for Guava’s collection types. But when added into an OSGi framework, these serializers can only be used for Guava 17, which isn’t generally useful. And while we could potentially remove Guava types from our own code, we wouldn’t be able to prevent third parties from introducing them again from theirs. It sounds like we’re going to need to rewrite `FOO`'s Guava version constraint as `[17,)`, which isn’t _remotely_ pretty but would work. But I will examine the OSGi listeners too, to see if we can get the framework to do this programmatically instead. Cheers, Chrus ---
**Author:** ![pkriens](https://yyz2.discourse-cdn.com/free1/user_avatar/bnd.discourse.group/pkriens/32/3_2.png) [@pkriens](https://bnd.discourse.group/u/pkriens)\ **Post date:** [January 18, 2021, 10:37am UTC](https://bnd.discourse.group/t/fixing-known-osgi-metadata-problems-when-installing-bundle/75/4 "2021-01-18T10:37:50Z")
> [@chrisr3](#): > > And while we could potentially remove Guava types from our own code, we wouldn’t be able to prevent third parties from introducing them again from theirs. I do not think that model is ever going to work. OSGi is an almost perfect model to build modular applications. and my customers are proving it daily. However, I’ve given up on the idea that it can integrate _unmodular_ applications. ---
**Author:** ![chrisr3](https://yyz2.discourse-cdn.com/free1/user_avatar/bnd.discourse.group/chrisr3/32/58_2.png) [@chrisr3](https://bnd.discourse.group/u/chrisr3)\ **Post date:** [January 18, 2021, 11:32am UTC](https://bnd.discourse.group/t/fixing-known-osgi-metadata-problems-when-installing-bundle/75/5 "2021-01-18T11:32:01Z")
We would be asking third parties to contribute modules written against our API; we don’t want to be unmodular here either. But this doesn’t mean that we can prevent those modules from using Guava internally, and the modules need to be able to serialize/deserialize their own data. ---
**Author:** ![pkriens](https://yyz2.discourse-cdn.com/free1/user_avatar/bnd.discourse.group/pkriens/32/3_2.png) [@pkriens](https://bnd.discourse.group/u/pkriens)\ **Post date:** [January 18, 2021, 2:19pm UTC](https://bnd.discourse.group/t/fixing-known-osgi-metadata-problems-when-installing-bundle/75/6 "2021-01-18T14:19:47Z")
I think we discussed this before? In your application imho the only solution is to force participants to carry their own dependencies in the private bundle area. I do not think sharing can work at that scale and clearly not on your required time frame. ---
**Author:** ![chrisr3](https://yyz2.discourse-cdn.com/free1/user_avatar/bnd.discourse.group/chrisr3/32/58_2.png) [@chrisr3](https://bnd.discourse.group/u/chrisr3)\ **Post date:** [January 22, 2021, 12:39pm UTC](https://bnd.discourse.group/t/fixing-known-osgi-metadata-problems-when-installing-bundle/75/7 "2021-01-22T12:39:36Z")
> I do not think sharing can work at that scale and clearly not on your required time frame. I _believe_ we can manage the _particular_ Guava issue I have described above 🤞. We obviously do want to isolate our users both from our own internals and from each other as much as possible, if only for the sake of our sanity. Does this mean that there is _no_ way for an OSGi framework to tweak its bundles’ requirements programmatically, before they can be resolved please? I did consider filtering the `InputStream` passed to: ```auto BundleContext.installBundle(String, InputStream) ``` However, that would only work for _unsigned_ bundles 🙁. Cheers, Chris ---
**Author:** ![bjhargrave](https://yyz2.discourse-cdn.com/free1/user_avatar/bnd.discourse.group/bjhargrave/32/10_2.png) [@bjhargrave](https://bnd.discourse.group/u/bjhargrave)\ **Post date:** [January 22, 2021, 1:04pm UTC](https://bnd.discourse.group/t/fixing-known-osgi-metadata-problems-when-installing-bundle/75/8 "2021-01-22T13:04:29Z")
There is no way in the OSGi framework specification to mutate bundle metadata during install/update. The only way would be to manipulate the InputStream as you noted. The Eclipse Equinox framework implementation does provide a number of non-standard framework hooks which may be of use here. I am not super familiar with them however. ---
**Author:** ![pkriens](https://yyz2.discourse-cdn.com/free1/user_avatar/bnd.discourse.group/pkriens/32/3_2.png) [@pkriens](https://bnd.discourse.group/u/pkriens)\ **Post date:** [January 23, 2021, 10:41am UTC](https://bnd.discourse.group/t/fixing-known-osgi-metadata-problems-when-installing-bundle/75/9 "2021-01-23T10:41:13Z")
You might want to take a look at the OSGi Connect specification. This will allow you to do whatever you want.