Hi Neil, Don't feel bad for me, I don't actually have to deal with this problem first-hand. I'm just providing some advice. This literally is one of those "I'm asking for a friend" situations :)
I assume the Require-Bundle / mandatory solution you are describing is the same as is documented here: http://wiki.osgi.org/wiki/Split_Packages. I can *almost* see how that would work, but for the third scenario I laid out below, it would fail if a single client bundle imported both the high-level Java API and the high-level Scala API. This might be unlikely, but I could imagine a situation where it would be necessary. Anyway, thanks for validating that I wasn't missing something obvious and that this is actually a tough nut to crack. Justin On Fri, Aug 1, 2014 at 5:06 PM, Neil Bartlett <[email protected]> wrote: > 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
