Yes, sorry, was on the road before. It uses semantic versioning to determine what matches and 7.24.1 is much less (99 less) than 7.24.100. It doesn’t compare them lexicographically. It treats each section as an integer.
Are you using the maven bundle plugin? If not, you should be. It, for a majority of use cases, “just works.” That version range you’re using will be problematic. Typically, you’d have a range of [7.24.0,8.0.0), meaning you need at least the 7.24.x minor version, because it includes a feature you need, but you don’t want 8.0.0, because that could include some compatibility breaks. Hope this helps, and sorry for my previous, short reply. On Tue, Apr 3, 2018 at 9:39 PM Raymond Auge <[email protected]> wrote: > I think that, as James was alluding to, your problem is in the package > import range you stated in your original message: > > "[7.24.0,7.24.1)" > > Do you know how the import range came to be so narrow? Typically the range > is something like > > "[7.24.0,7.25.0)" > > Perhaps the import policy was altered? > > - Ray > > > On Tue, Apr 3, 2018, 19:10 Katsuya Tomioka, <[email protected]> > wrote: > > > Thanks for the reply. I hugely omitted details, I realized. > > > > > > This is the error from gogo with felix 5.6.10: > > > > ERROR: Bundle rex-osgi [13] Error starting file:/Users/kt/work/felix/ > > > > > felix-framework-5.6.10/bundle/com.basistech.rex-je-rex-osgi-7.33.101.c59.2.jar > > (org.osgi.framework.BundleException: Unable to resolve rex-osgi [13](R > > 13.0): missing requirement [rex-osgi [13](R 13.0)] osgi.wiring.package; > > > > > (&(osgi.wiring.package=com.basistech.rbl.osgi)(version>=7.24.0)(!(version>=7.24.1))) > > Unresolved requirements: [[rex-osgi [13](R 13.0)] osgi.wiring.package; > > (&(osgi.wiring.package=com.basistech.rbl.osgi)(version>= > > 7.24.0)(!(version>=7.24.1)))]) > > org.osgi.framework.BundleException: Unable to resolve rex-osgi [13](R > > 13.0): missing requirement [rex-osgi [13](R 13.0)] osgi.wiring.package; > > > > > (&(osgi.wiring.package=com.basistech.rbl.osgi)(version>=7.24.0)(!(version>=7.24.1))) > > Unresolved requirements: [[rex-osgi [13](R 13.0)] osgi.wiring.package; > > (&(osgi.wiring.package=com.basistech.rbl.osgi)(version>= > > 7.24.0)(!(version>=7.24.1)))] > > at > org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4149) > > at org.apache.felix.framework.Felix.startBundle(Felix.java:2119) > > at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373) > > at org.apache.felix.framework.FrameworkStartLevelImpl.run( > > FrameworkStartLevelImpl.java:308) > > > > The package is used in component interface. > > > > lb of exporting (component) bundles: > > 9|Active | 1|rbl-osgi (7.24.0.c592)|7.24.0.c592 > > 10|Active | 1|rbl-osgi (7.24.104.c592)|7.24.104.c592 > > > > scr:list lists two components (one for each bundle): > > [ 9] com.basistech.rbl.osgi.impl.BlComponentService enabled > > [ 1] [satisfied ] > > ... > > > > g! inspect cap service 9 (correct one) > > rbl-osgi [9] provides: > > ---------------------- > > service; com.basistech.rbl.osgi.RblRosetteComponentService with > properties: > > ... > > > > I can see the same thing for the bundle 10. > > [ 10] com.basistech.rbl.osgi.impl.BlComponentService enabled > > [ 5] [satisfied ] > > > > > > Export: > > com.basistech.rbl.osgi {version=7.24.0.c592} > > > > (from 7.24.104) > > com.basistech.rbl.osgi {version=7.24.104.c592} > > > > Importing side: > > com.basistech.rbl.osgi {version=[7.24.0,7.24.1)} > > > > > > On Tue, Apr 3, 2018 at 5:27 PM, Neil Bartlett <[email protected]> > > wrote: > > > > > > > > > On 3 Apr 2018, at 22:17, Katsuya Tomioka <[email protected]> > > > wrote: > > > > > > > > Felix users, > > > > > > > > I have same bundles (say "A") installed only different by micro > > versions, > > > > 7.24.0 and 7.24.100. I have then another ("B") imports packages from > > "A" > > > > such that: "[7.24.0,7.24.1)". This works fine if I installed 7.24.0 > > only. > > > > But soon as 7.24.100 installed, the bundle B fails to resolve with > > > > unresolved requirements. > > > > > > > > Would that be possible to resolve the bundle B even with both > versions > > > of A > > > > installed? Or is even allowed in the spec? > > > > > > This is definitely possible. > > > > > > Please post the actual error message so that we can work out what is > > > happening. It would also be helpful to see: > > > > > > * the list of bundles; > > > * the exact exports of the “A” bundles, and; > > > * the exact imports of the “B” bundle. > > > > > > Regards, > > > Neil > > > > > > > > > > > > > > Thanks, > > > > > > > > -Katsuya > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > >
