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
