> 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
