On 5 February 2010 16:02, 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", ... > ^ 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 > -- Cheers, Stuart
