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

Reply via email to