Thank you all for the replies with all the useful information and pointers.
For versioning Tuscany bundles themselves, we are using maven-bundle-plugin at the moment, which gives us import and "uses" clauses with version="2.0.0". Since this includes all versions from 2.0 to infinity, and we are not currently addressing execution of two different versions of Tuscany side-by-side, the default looks sufficient. We could change it to "[2.0.0,3.0.0)" to make it more specific, but either way, it should be fine for now. I am still not entirely sure about versioning of 3rd party libraries distributed with Tuscany though. Since Tuscany is used to assemble SOA applications, Tuscany uses a large number of 3rd party libraries to provide different bindings and implementation types. Many of these 3rd party libraries may also be used by applications (either directly from Tuscany or from a different source). If for example, Tuscany's version of wsdl4j used import version "[1.6.2, 2.0,0)", and this version of Tuscany doesn't work with wsdl4j version 1.7, doesn't the version range "[1.6.2, 2.0,0)" prevent an application from installing and using version 1.7 along with Tuscany for something else? So should the version range only specifically include the version range that Tuscany has been tested against? And then we run into problems with too narrow version ranges. And what happens when an application is using wsdl4j from SpringSource or another repository where a different version range is included? How do we ensure that Tuscany and applications can all coexist? Thank you... Regards, Rajini On 6/4/08, Mirko Jahn <[EMAIL PROTECTED]> wrote: > > 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 >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
