Yes David, The bundles used at compile-time and deployed are the same, The issue comes not at runtime, but at installation time using Equinox P2. We package our bundles in features and using P2 we install it to the runtime. This is where, version-range is giving us trouble, P2 complains about missing requirements for some bundles in features. I will further look into it and see what could be the problem.
Thanks for all your suggestions. Regards, Dileepa On Wed, Nov 7, 2012 at 11:44 PM, David Jencks <[email protected]>wrote: > If bnd is generating bundles with export-package version equal to bundle > version when you don't explicitly specify the export-package version, then > if you use those bundles at runtime, the imports and exports should match > up. Are you sure you are using the same compile time dependencies as run > time dependencies? > > thanks > david jencks > > On Nov 7, 2012, at 10:07 AM, Dileepa Jayakody wrote: > > > Yes David, I think I'm seeing what's you have explained. Although we > > haven't defined a version in the Export-Package instruction, the > > bundle-plugin has added the bundle's version to the Export in the > generated > > bundle manifest. And when using that bundle as a compile dependency in > the > > consumer bundles, a version range has being added. > > > > Thanks Neil for your clarifications, so basically as I understand I have > to > > make sure the compile-time dependency used in the consumer bundle should > > match the bundle-version of the producer bundle. > > > > Thanks, > > Dileepa > > > > > > On Wed, Nov 7, 2012 at 10:43 PM, David Jencks <[email protected] > >wrote: > > > >> I have a slight recollection that with some new versions of bnd I've > seen > >> bnd use the bundle version when the export package version is missing. > I > >> hope I've made this up :-). I recall that there was something that got > me > >> to add export versions to the few bundles that were missing them. If I > >> didn't make this up it might possibly explain what Dileepa is seeing. > >> > >> thanks > >> david jencks > >> > >> On Nov 7, 2012, at 3:44 AM, Neil Bartlett wrote: > >> > >>> You said "the exporting package doesn't have a version". But it must > >>> actually have a version because otherwise maven-bundle-plugin would not > >> add > >>> the range on the Import-Package statement! The only thing I can think > of > >> is > >>> you are building against versioned bundles but deploying different, > >>> un-versioned bundles during runtime. Which is a bit of an odd thing to > >> do... > >>> > >>> Anyway if you use the same bundles/jars during both compilation and > >> during > >>> runtime, then everything should be fine (which is pretty much what > Felix > >>> said). > >>> > >>> Regards > >>> Neil > >>> > >>> On Wed, Nov 7, 2012 at 11:34 AM, Dileepa Jayakody <[email protected]> > >> wrote: > >>> > >>>> Hi Felix, > >>>> > >>>> Thanks for your reply. > >>>> > >>>> The main problem is we haven't defined versions for Exported packages > in > >>>> the producer bundles. > >>>> > >>>> eg: In org.foo.bar:1.0.2 bundle we define > >>>> Export-Package: org.foo.bar.*; > >>>> > >>>> So when building the bundle the producer bundle's Export-Package is > >> defined > >>>> without any version. The problem is when org.foo.bar.* is used as an > >>>> Import-Package in a consumer bundle. Even though we define > >> Import-Package: > >>>> org.foo.bar.*; (without a version defined), when the consumer bundle > is > >>>> built the bundle-plugin has injected a version range like > [1.0.0,2.0.0). > >>>> > >>>> The problem occurs when installing the bundles to our runtime using > >>>> Equinox, as it first resolves the bundle resolutions for Imports, > >> Exports. > >>>> So regardless of the compile-time dependency used to build the > consumer > >>>> bundle, we don't want to have a version injected to the org.foo.bar.* > >>>> Import, because the exporting package doesn't have a version. > >>>> Is there any mechanism for us to stop the bundle-plugin from injecting > >> the > >>>> version for the Import-Package here? > >>>> In several cases where we faced this issue, we have defined the > >>>> Import-Package: org.foo.bar.*;*version="0.0.0"* so that it will get > >> wired > >>>> to any version exported for the org.foo.bar.* > >>>> But using version="0.0.0" hack for all packages exported without a > >> defined > >>>> version is not manageable at this moment. > >>>> > >>>> I hope the problem we are facing, is clear to you. The best solution > >> here > >>>> would be to define versions for Exports and use them appropriately in > >>>> relevant Imports. > >>>> But at the moment there are so many bundles that are exporting > packages > >>>> without a defined version. > >>>> So can you please suggest an alternate mechanism to handle Imports > >> Exports > >>>> with no versions specified in the bundle-plugin? Is there a mechanism > we > >>>> can tell the bundle-plugin not to compute version-ranges for Imports? > >> Or is > >>>> there an older version of the bundle-plugin this functionality is not > >>>> available? > >>>> > >>>> Thanks a lot! > >>>> > >>>> Regards, > >>>> Dileepa > >>>> > >>>> > >>>> > >>>> > >>>> On Wed, Nov 7, 2012 at 2:26 PM, Felix Meschberger <[email protected] > >>>>> wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> Am 07.11.2012 um 08:54 schrieb Dileepa Jayakody: > >>>>> > >>>>>> Hi All, > >>>>>> > >>>>>> We are having a problem using maven-bundle-plugin to build our > >> bundles, > >>>>>> where it injects a version-range (I think it computes the version > >> range > >>>>>> from the compile-time maven-dependency) to the bundle's > >>>> Import-Packages. > >>>>>> > >>>>>> For eg : when I have specified an Import-Package: org.foo.bar; The > >>>> plugin > >>>>>> injects a version range like Import-Package: > >>>> org.foo.bar;version="[1.0.0, > >>>>>> 2.0.0)" probably by computing from the compile time dependency > version > >>>> of > >>>>>> the maven artifact exposing org.foo.bar package. > >>>>>> > >>>>>> The problem is many of our producer bundles are not exporting their > >>>>>> packages with versions. So when the bundle-plugin computes and > injects > >>>> a > >>>>>> version range to relevant consumer bundle's Import-Package, the > >>>>> resolution > >>>>>> get broken because there is no exporter for that package within the > >>>>>> required version-range. > >>>>>> I know, we should manage versions in Exports/Imports properly but > it's > >>>>> not > >>>>>> manageable at the moment with the number of bundles has exceeded > 300. > >>>>> > >>>>> So your dependencies expose exported package version and your > deployed > >>>>> bundles don't ? This sounds like a strange situation. > >>>>> > >>>>> Looks like you are building against newer versions than the deployed > >> ones > >>>>> ? If so, I suggest to build against the same versions as you have > >>>> deployed. > >>>>> > >>>>> In general my take on this is to always compile to the lowest version > >>>>> dependency that meets the (API) needs of the code you are compiling. > >> This > >>>>> way your lower version in the range will really expose what the > bundle > >>>>> needs and you will have less surprises at deployment time. > >>>>> > >>>>> The idea is that you develop with a certain version of a dependency > >> (even > >>>>> though Maven's dependencies and OSGi's Import-Package need not be the > >>>> same) > >>>>> and that you expect at least that version of the dependency or a > newer > >>>> one > >>>>> to be actually deployed. > >>>> > >>>> > >>>>> Regards > >>>>> Felix > >>>>> > >>>>>> > >>>>>> Can I please know how can I explicitly avoid the version-range > >> injected > >>>>> to > >>>>>> Import-Package? Is this feature of computing version-range for > Imports > >>>>>> added to maven-bundle-plugin (bnd) in a recent released version? > >>>>>> We are using 2.3.5 version of the bundle-plugin. > >>>>>> If this feature has been added to a recent version of the plugin , > can > >>>>> you > >>>>>> please specify an older version of the bundle-plugin that doesn't > >>>> compute > >>>>>> version ranges for Import-Package? > >>>>>> At the moment our immediate requirement is to stop adding > >>>> version-ranges > >>>>>> for Import-Package > >>>>>> > >>>>>> Appreciate your insight on this. > >>>>>> > >>>>>> Thanks, > >>>>>> Dileepa > >>>>> > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: [email protected] > >>>>> For additional commands, e-mail: [email protected] > >>>>> > >>>>> > >>>> > >>>> > >>>> -- > >>>> Dileepa Jayakody, > >>>> Software Engineer, WSO2 Inc. > >>>> Lean . Enterprise . Middleware > >>>> > >>>> Mobile : +94777-857616 > >>>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > > > -- > > Dileepa Jayakody, > > Software Engineer, WSO2 Inc. > > Lean . Enterprise . Middleware > > > > Mobile : +94777-857616 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Dileepa Jayakody, Software Engineer, WSO2 Inc. Lean . Enterprise . Middleware Mobile : +94777-857616
