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 >
