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]
