Hmm, actually I wanted to express that, but re-reading my post... it is anything but clear to me too. Maybe this here would have been better: "Never depend on a single [string] version and [therefore implicitly] all new upcoming versions [as well]." Thanks for pointing that out Peter! I think next time, I just shouldn't write in the middle of the night. ;-)
To clarify the problem even more, consider you have the mentioned import: Import-Package: org.osgi.framework;version="1.3.0" This will wire you to any new version of the org.osgi.framework package higher than 1.3.0. This also includes (potentially) incompatible versions like 2.6.2 or even higher. Because of the lack of a defined version range the container will always wire the latest version of the package to your bundle and not the one you might be compatible with, even if multiple (compatible) versions of your package are available in the container. Actually the real benefit from my point of view is the handling of these dependencies. If your bundles dependencies can't be satisfied, it just won't resolve. Once you noticed that, it's a peace of cake figuring out that a certain package (version) is not available. Now imagine the former case, where you have the wrong version wired to your bundle. You can't tell what the problem is, depending on the problem, you might not even be able to tell what bundle is responsible for the problem right away! >From my personal point of view, it is not clear, why version="1.3.0" implies version="[1.3.0;infinite)" and not by default implies version="[1.3.0;*nextmajor*)". Anyway, as long as you know about it, it is no problem to work with it. Cheers, Mirko On Wed, Jun 4, 2008 at 8:33 AM, Peter Kriens <[EMAIL PROTECTED]> wrote: >> Import-Package: org.osgi.framework;version="1.3.0" > This actually is [1.3.0,infinity), so it is not depending on a > point version. > Kind regards, > Peter Kriens > > > > On 4 jun 2008, at 01:09, Mirko Jahn 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 > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
