Thanks a lot, Stuart, I did not know about the bundle-symbolic-name clause: that's so simple !
/pierre On Fri, Feb 5, 2010 at 9:02 AM, Stuart McCulloch <[email protected]> wrote: > 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 >
