Hi Rajini, this is actually my most favorite topic ;-) So, please allow me to elaborate a little bit on that one.
As a starter, I can highly recommend the Eclipse wiki on that [1] and maybe [2]. If you want to safe you some time wrapping 3rd party libraries, first take a look at the following repositories, which all contain several versions of 3rd party libraries [3], [4] and [5]. Further more, I would strongly recommend you to design your dependencies only on package level with version ranges on major versions like the following example illustrates (and never on the service segment): Import-Package: org.osgi.framework;version="[1.3.0,2.0.0)" In this very example, if you don't use the added functionality in 1.3.0, you should even use: Import-Package: org.osgi.framework;version="[1.2.0,2.0.0)" Always use the smallest compatible version! Never depend on a single version and all new upcoming versions, because this might break, without you noticing it: Import-Package: org.osgi.framework;version="1.3.0" Actually your unit tests should ensure that this won't happen, but this way you're on the safe side. When you export packages, always provide the version and the uses clause, if necessary! Import your exports is actually considered a best practice and helps your container to create the correct class space [6] (I actually blogged about oddities with fragments recently[7] slightly touching the import/export pattern). If you're very nice and are providing a special "implementation" of a well known API, which is exported (like SLF4J for instance), you event might provide a property containing you as vendor, so one can bind an import not only on the API, but also on the vendor if necessary. Taking all this into account, you should be pretty safe. The container takes care of the rest and ideally you will not need to uninstall any version! It should work just magically :-) Bundle versions are now no longer that important, but should still follow the guidlines outlined in [1]. Especially if the bundle provides services, but no actual API/packages. Version changes are then mostly reflected in the version of the bundle itself. The general question on how to bundle APIs/SPIs and implementations were discussed just yesterday on this list as well and I can certainly recommend you the read. It is kinda late here in Germany, so I hope I didn't forget anything. If so, OSGi experts out there, please don't hesitate to correct me or add stuff I didn't mention. Cheers, Mirko Btw.: Adding manifest headers won't work for all libraries. Some have to be changed in order to work in OSGi. (F.i. if they rely on the ContextClassLoader or use Class.forName(className)) Further issues with wrapping 3rd party libraries have also extensively discussed on this list, so a search might bring you even more insight, what might be involved here. References: [1] http://wiki.eclipse.org/index.php/Version_Numbering [2] http://wiki.eclipse.org/Adding_Bundles_to_Orbit [3] http://download.eclipse.org/tools/orbit/downloads/ [4] http://www.osgi.org/Repository/HomePage [5] http://www.springsource.com/repository [6] http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html [7] http://osgi.mjahn.net/2008/03/13/half-bundle-half-jar-–-the-nature-of-fragment-a-blessing-or-a-curse/ On Tue, Jun 3, 2008 at 11:10 PM, Rajini Sivaram <[EMAIL PROTECTED]> wrote: > > > Hello, > > Are there guidelines that would be useful in defining version constraints > when OSGi-enabling 3rd party libraries? Typically, should constraints be made > as broad as possible to enable flexible resolution, or should they be made as > narrow as possible to enable multiple versions to coexist? The OSGi > specification says "the import should be as unconstrained as possible to > allow the resolver maximum flexibility" in the context of importing exported > packages. But doesn't too unconstrained also mean that multiple variants > cannot execute side-by-side? > > To add some context to the question, we are looking at OSGi-enabling Tuscany > which uses around 150 3rd party libraries. Many of these libraries are likely > to be shared with applications, and in some cases, applications may want to > use a different version of a library and share it with Tuscany, and in some > other cases applications may want to use a different version of a 3rd party > library from Tuscany without any sharing. Is there a recommended versioning > technique which would do the right thing in a vast majority of cases? Is > there any way that we can completely avoid applications ever having to > uninstall Tuscany's version of 3rd party bundles, regardless of what > sharing/isolation they require? > > > Thank you... > > Regards, > > Rajini > _______________________________________________ > 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
