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]
