On 5 February 2010 15:52, Pierre De Rop <[email protected]> wrote:
> Replying to myself ... > > I could also chose to embed the jaxb third-party library into B2 (using > Bundle-ClassPath), and don't import at all the jaxb api at all. > (Actually, third party libraries like jaxb use extensively thread context > class loader, and may be it's safer to embed such libraries than sharing > them among bundles ...) > > maybe this would be the best and easiest solution ... correct ? > if this purely is an implementation detail then embedding is a reasonable decision BTW, if you want to always get a package from the JDK then the easiest solution is to add a 'bundle-symbolic-name' constraint to the package so it always comes from the system bundle - for example: Import-Package: com.acme.foo;bundle-symbolic-name=system.bundle", ... HTH /pierre > > On Fri, Feb 5, 2010 at 8:16 AM, Pierre De Rop <[email protected] > >wrote: > > > Hello everyone, > > > > I am using Ant, as well as Bnd, with the following Bnd directives in > order > > to allow my bundles to import APIs using a version range (because I have > > some multi-version requirements). > > > > -versionpolicy "[${version;==;$...@}},${version;+;$...@}})"* > > -> This clause allows a Using Service bundle to Import a Service API > using > > a versionrange of the form *[x.y,x+1)*. This means accept any version > > starting with a minimum number up to the next breaking API chnage > identified > > by a new major version number. > > > > -versionpolicy-impl "[${version;==;$...@}},${version;=+;$...@}})"* > > -> This clause allows a Service Providing bundle to import the API it > > implements with the range of the form *[x.y,x.y+1)*. This means accept > any > > increment in the micro and qualifier parts. But as soon as the minor > > version number changes, consider this an incompatibility. > > > > Ok, now I have the following usecase: > > > > - I'm using a third party library bundle, which exports the jaxb API > > (javax.xml.bind) with version = 2.1.4 > > - I am using jdk1.6, and the javax.xml.bind is also exported by the > > framework in the system package, with version = 1.6.0 (I'm using jdk > 1.6) > > - Bundle B1 is compiled with the jaxb bundle it it's classpath. So, > Bnd > > generates automatically (thanks to the versionpolicy directive) a nice > > Import-Package header, with javax.xml.bind;version="[2.1,3)" > > - But bundle B2 wants to be wired* with the jdk javax.xml.bind,* *not > > with the 2.1.4 jaxb.* > > > > My question is: what is the best way to ensure that B2 will be wired with > > the proper jaxb jdk version ? > > > > -> For now, I accommodate with setting the following directive in the bnd > > file of B2: > > > > Import-Package: javax.xml.bind.*; version="[1.6,1.6]", * > > > > But I don't think that it's a nice thing to hard code the jdk version in > my > > B2 bundle bnd directive's file, because I will to update my bnd file, > when I > > will switch to jdk 1.7 ... > > I'm also not comfortable with importing jaxb with version = 1.6.0, > because > > 1.6.0 is the jdk version, not a jaxb version. > > > > Another option would consist in updating the felix system package and > > append a "tag=JDK" in the exported system package list. And in B2, I > could > > then import jaxb like this: > > > > Import-Package: javax.xml.bind.*; tag=JDK, * > > > > This way is probably a little bit smarter that hard coding the 1.6 > version, > > but I then have to configure my felix fwk and add that specific "tag=JDK" > > header .. > > > > What do you think ? > > > > > > thanks; > > /pierre > > > -- Cheers, Stuart
