Anger is of course but one possible reaction; there is also laughter or indeed tears.
If this is the same org.mongodb.mongo-java-driver as I am using in a project then 1. I think I'll go for tears and 2. there are about 300 classes in com.mongodb itself (not counting the subpackages, which each contain much fewer classes - which is itself a significant statistic). That's quite a lot of classes to have in one package, although I'm sure there are many worse cases Out There. If the driver maintainers have identified some classes as being low-level and some as being high-level then they should be able to split them into two packages (say, com.mongodb.binding.java and com.mongodb.common), in such a way that com.mongodb.binding.java depends on com.mongodb.common - and your problem is solved. If they can't do that then they have a problem which you cannot solve for them by concocting fancy headers in a manifest. And they should solve that problem now, while they have "only" 300 classes and a handful of Java-related language bindings to deal with. The modularity which OSGi provides is based on packages. Expecting OSGi to deliver modularity when there is no package structure is, uh, optimistic. Good luck, Chris > Hi Justin. > > First, what a horrible, horrible situation. I can only sympathise with > you, while boiling with anger at the developers who did this! > > There are ways of dealing with this, using a combination of Require-Bundle > along with mandatory attributes on package exports⦠but I would strongly > caution against trying to go down this route. It will inevitably cause > much more complexity for the downstream users. > > Why not just combine all parts of the API into one bundle? Why do they > want to ship as separate bundles? Surely it canât just be to save disk > space! > > Regards, > Neil > > > > On 1 August 2014 at 21:39:39, Justin Edelson ([email protected]) > wrote: > > Hi, > I'm trying to work out a split package scenario which seems very > tricky, but I wanted to tap into this list's collective wisdom as > split packages are not my thing. > > The library in question is the MongoDB Java Driver > (https://github.com/mongodb/mongo-java-driver) and specifically the > package com.mongodb. Leaving aside the question of how it got to this > state, at present there are basically two different APIs in this > package. There is a low-level API (e.g. classes like WriteConcern, > ReadPreference, and MongoException) and then a high-level API (e.g. > MongoClient, DB, and DBConnection). The driver maintainers want to > ship these APIs in separate bundles. There are *other* high-level APIs > such as for other JVM languages like Scala and Clojure. The > implementations of those APIs should only depend up the low-level API. > In all cases, the classes and interfaces within the low-level API are > exposed dependencies of the high-level APIs, e.g. DBConnection has > methods which throw MongoException (in other words, if these were two > separate packages, the export of the high-level API would have a uses > clause pointing to the low-level API). > > So, the question (at least for me) becomes how to export the packages > in such a way that allows for the following cases, while of course > retaining backwards compatibility: > > 1. Deploying the Java high-level API and the low-level API. > 2. Deploying the Scala high-level API and the low-level API. > 3. Deploying both the Java and Scala high-level APIs and the low-level > APIs. > > Any suggestions would be welcome. > > Regards, > Justin > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
