You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Katsuya Tomioka <ka...@gmail.com> on 2018/04/03 21:17:14 UTC
Resolving to micro version
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?
Thanks,
-Katsuya
Re: Resolving to micro version
Posted by James Carman <ja...@carmanconsulting.com>.
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 <ra...@liferay.com>
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, <ka...@gmail.com>
> 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 <nj...@gmail.com>
> > wrote:
> >
> > >
> > > > On 3 Apr 2018, at 22:17, Katsuya Tomioka <ka...@gmail.com>
> > > 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: users-unsubscribe@felix.apache.org
> > > For additional commands, e-mail: users-help@felix.apache.org
> > >
> > >
> >
>
Re: Resolving to micro version
Posted by Karl Pauls <ka...@gmail.com>.
Can you please share the manifests/headers of the bundles involved with us?
regards,
Karl
On Wed, Apr 4, 2018 at 2:04 PM, Katsuya Tomioka
<ka...@gmail.com> wrote:
> Thanks for the explanation. The narrow import range is intentional, I
> manually set the import in bnd (via bnd-maven-pugin) to satisfy functional
> requirements; I need to consume the version specifically. The runtime
> currently happened to have both versions of the component.
>
>
> g! inspect cap osgi.wiring.package 9
> 08:01:30
> rbl-osgi [9] provides:
> ----------------------
> osgi.wiring.package [EMPTY]
> g! inspect cap osgi.wiring.package 10
> 08:01:49
> rbl-osgi [10] provides:
> -----------------------
> osgi.wiring.package; com.basistech.rbl.osgi 7.24.104.c592 required by:
> rbl-osgi [9]
> g! inspect req osgi.wiring.package 13
> 08:01:57
> Bundle 13 is not resolved.
>
> Thanks,
> -Katsuya
>
>
> On Tue, Apr 3, 2018 at 11:58 PM, Neil Bartlett <nj...@gmail.com> wrote:
>
>> What Ray said is absolutely true, but I don’t think it actually explains
>> the problem. As far as I can tell, the range should actually catch the
>> export from the "rbl-osgi (7.24.0.c592)” bundle.
>>
>> Katsuya-san: just to be sure, please type the following commands and send
>> the output:
>>
>> inspect cap osgi.wiring.package 9
>> inspect cap osgi.wiring.package 10
>> inspect req osgi.wiring.package 13
>>
>> Regards,
>> Neil
>>
>>
>>
>> > On 4 Apr 2018, at 03:39, Raymond Auge <ra...@liferay.com> 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, <ka...@gmail.com>
>> > 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 <nj...@gmail.com>
>> >> wrote:
>> >>
>> >>>
>> >>>> On 3 Apr 2018, at 22:17, Katsuya Tomioka <ka...@gmail.com>
>> >>> 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: users-unsubscribe@felix.apache.org
>> >>> For additional commands, e-mail: users-help@felix.apache.org
>> >>>
>> >>>
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Resolving to micro version
Posted by Katsuya Tomioka <ka...@gmail.com>.
That explains. I had particularly hard time imagining the clause in the
spec. (now I have an example.)
Thanks all for help.
-Katsuya
On Wed, Apr 4, 2018 at 8:20 AM, Neil Bartlett <nj...@gmail.com> wrote:
> Thank you, now the answer is clear.
>
> You can see that the lower version of rbl-osgi (bundle ID 9) has zero
> active exports, and it is importing the package com.basistech.rbl.osgi from
> the higher version of itself. This is because rbl-osgi has both an import
> and an export of that package. When this happens, OSGi chooses either the
> import OR the export to be active, but never both. When the higher version
> is present, the export of the lower version is hidden. This is why bundle
> 13 does not resolve: because of its tight import range, there is no
> matching export.
>
> Like Ray, I think that your tight import range in bundle 13 is wrong. You
> should not have semantic differences at the level of the micro version.
> However if you really, really need such a tight range then you should also
> use the same tight range on the import from bundle rbl-osgi.
>
> Regards,
> Neil
>
>
>
> On Wed, Apr 4, 2018 at 1:04 PM, Katsuya Tomioka <katsuya.tomioka@gmail.com
> >
> wrote:
>
> > Thanks for the explanation. The narrow import range is intentional, I
> > manually set the import in bnd (via bnd-maven-pugin) to satisfy
> functional
> > requirements; I need to consume the version specifically. The runtime
> > currently happened to have both versions of the component.
> >
> >
> > g! inspect cap osgi.wiring.package 9
> > 08:01:30
> > rbl-osgi [9] provides:
> > ----------------------
> > osgi.wiring.package [EMPTY]
> > g! inspect cap osgi.wiring.package 10
> > 08:01:49
> > rbl-osgi [10] provides:
> > -----------------------
> > osgi.wiring.package; com.basistech.rbl.osgi 7.24.104.c592 required by:
> > rbl-osgi [9]
> > g! inspect req osgi.wiring.package 13
> > 08:01:57
> > Bundle 13 is not resolved.
> >
> > Thanks,
> > -Katsuya
> >
> >
> > On Tue, Apr 3, 2018 at 11:58 PM, Neil Bartlett <nj...@gmail.com>
> > wrote:
> >
> > > What Ray said is absolutely true, but I don’t think it actually
> explains
> > > the problem. As far as I can tell, the range should actually catch the
> > > export from the "rbl-osgi (7.24.0.c592)” bundle.
> > >
> > > Katsuya-san: just to be sure, please type the following commands and
> send
> > > the output:
> > >
> > > inspect cap osgi.wiring.package 9
> > > inspect cap osgi.wiring.package 10
> > > inspect req osgi.wiring.package 13
> > >
> > > Regards,
> > > Neil
> > >
> > >
> > >
> > > > On 4 Apr 2018, at 03:39, Raymond Auge <ra...@liferay.com>
> > 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, <
> katsuya.tomioka@gmail.com
> > >
> > > > 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 <njbartlett@gmail.com
> >
> > > >> wrote:
> > > >>
> > > >>>
> > > >>>> On 3 Apr 2018, at 22:17, Katsuya Tomioka <
> katsuya.tomioka@gmail.com
> > >
> > > >>> 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: users-unsubscribe@felix.apache.org
> > > >>> For additional commands, e-mail: users-help@felix.apache.org
> > > >>>
> > > >>>
> > > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > For additional commands, e-mail: users-help@felix.apache.org
> > >
> > >
> >
>
Re: Resolving to micro version
Posted by Neil Bartlett <nj...@gmail.com>.
Thank you, now the answer is clear.
You can see that the lower version of rbl-osgi (bundle ID 9) has zero
active exports, and it is importing the package com.basistech.rbl.osgi from
the higher version of itself. This is because rbl-osgi has both an import
and an export of that package. When this happens, OSGi chooses either the
import OR the export to be active, but never both. When the higher version
is present, the export of the lower version is hidden. This is why bundle
13 does not resolve: because of its tight import range, there is no
matching export.
Like Ray, I think that your tight import range in bundle 13 is wrong. You
should not have semantic differences at the level of the micro version.
However if you really, really need such a tight range then you should also
use the same tight range on the import from bundle rbl-osgi.
Regards,
Neil
On Wed, Apr 4, 2018 at 1:04 PM, Katsuya Tomioka <ka...@gmail.com>
wrote:
> Thanks for the explanation. The narrow import range is intentional, I
> manually set the import in bnd (via bnd-maven-pugin) to satisfy functional
> requirements; I need to consume the version specifically. The runtime
> currently happened to have both versions of the component.
>
>
> g! inspect cap osgi.wiring.package 9
> 08:01:30
> rbl-osgi [9] provides:
> ----------------------
> osgi.wiring.package [EMPTY]
> g! inspect cap osgi.wiring.package 10
> 08:01:49
> rbl-osgi [10] provides:
> -----------------------
> osgi.wiring.package; com.basistech.rbl.osgi 7.24.104.c592 required by:
> rbl-osgi [9]
> g! inspect req osgi.wiring.package 13
> 08:01:57
> Bundle 13 is not resolved.
>
> Thanks,
> -Katsuya
>
>
> On Tue, Apr 3, 2018 at 11:58 PM, Neil Bartlett <nj...@gmail.com>
> wrote:
>
> > What Ray said is absolutely true, but I don’t think it actually explains
> > the problem. As far as I can tell, the range should actually catch the
> > export from the "rbl-osgi (7.24.0.c592)” bundle.
> >
> > Katsuya-san: just to be sure, please type the following commands and send
> > the output:
> >
> > inspect cap osgi.wiring.package 9
> > inspect cap osgi.wiring.package 10
> > inspect req osgi.wiring.package 13
> >
> > Regards,
> > Neil
> >
> >
> >
> > > On 4 Apr 2018, at 03:39, Raymond Auge <ra...@liferay.com>
> 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, <katsuya.tomioka@gmail.com
> >
> > > 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 <nj...@gmail.com>
> > >> wrote:
> > >>
> > >>>
> > >>>> On 3 Apr 2018, at 22:17, Katsuya Tomioka <katsuya.tomioka@gmail.com
> >
> > >>> 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: users-unsubscribe@felix.apache.org
> > >>> For additional commands, e-mail: users-help@felix.apache.org
> > >>>
> > >>>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
Re: Resolving to micro version
Posted by Katsuya Tomioka <ka...@gmail.com>.
Thanks for the explanation. The narrow import range is intentional, I
manually set the import in bnd (via bnd-maven-pugin) to satisfy functional
requirements; I need to consume the version specifically. The runtime
currently happened to have both versions of the component.
g! inspect cap osgi.wiring.package 9
08:01:30
rbl-osgi [9] provides:
----------------------
osgi.wiring.package [EMPTY]
g! inspect cap osgi.wiring.package 10
08:01:49
rbl-osgi [10] provides:
-----------------------
osgi.wiring.package; com.basistech.rbl.osgi 7.24.104.c592 required by:
rbl-osgi [9]
g! inspect req osgi.wiring.package 13
08:01:57
Bundle 13 is not resolved.
Thanks,
-Katsuya
On Tue, Apr 3, 2018 at 11:58 PM, Neil Bartlett <nj...@gmail.com> wrote:
> What Ray said is absolutely true, but I don’t think it actually explains
> the problem. As far as I can tell, the range should actually catch the
> export from the "rbl-osgi (7.24.0.c592)” bundle.
>
> Katsuya-san: just to be sure, please type the following commands and send
> the output:
>
> inspect cap osgi.wiring.package 9
> inspect cap osgi.wiring.package 10
> inspect req osgi.wiring.package 13
>
> Regards,
> Neil
>
>
>
> > On 4 Apr 2018, at 03:39, Raymond Auge <ra...@liferay.com> 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, <ka...@gmail.com>
> > 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 <nj...@gmail.com>
> >> wrote:
> >>
> >>>
> >>>> On 3 Apr 2018, at 22:17, Katsuya Tomioka <ka...@gmail.com>
> >>> 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: users-unsubscribe@felix.apache.org
> >>> For additional commands, e-mail: users-help@felix.apache.org
> >>>
> >>>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Resolving to micro version
Posted by Neil Bartlett <nj...@gmail.com>.
What Ray said is absolutely true, but I don’t think it actually explains the problem. As far as I can tell, the range should actually catch the export from the "rbl-osgi (7.24.0.c592)” bundle.
Katsuya-san: just to be sure, please type the following commands and send the output:
inspect cap osgi.wiring.package 9
inspect cap osgi.wiring.package 10
inspect req osgi.wiring.package 13
Regards,
Neil
> On 4 Apr 2018, at 03:39, Raymond Auge <ra...@liferay.com> 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, <ka...@gmail.com>
> 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 <nj...@gmail.com>
>> wrote:
>>
>>>
>>>> On 3 Apr 2018, at 22:17, Katsuya Tomioka <ka...@gmail.com>
>>> 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: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Resolving to micro version
Posted by Raymond Auge <ra...@liferay.com>.
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, <ka...@gmail.com>
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 <nj...@gmail.com>
> wrote:
>
> >
> > > On 3 Apr 2018, at 22:17, Katsuya Tomioka <ka...@gmail.com>
> > 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: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
Re: Resolving to micro version
Posted by Katsuya Tomioka <ka...@gmail.com>.
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 <nj...@gmail.com> wrote:
>
> > On 3 Apr 2018, at 22:17, Katsuya Tomioka <ka...@gmail.com>
> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Resolving to micro version
Posted by Neil Bartlett <nj...@gmail.com>.
> On 3 Apr 2018, at 22:17, Katsuya Tomioka <ka...@gmail.com> 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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Resolving to micro version
Posted by James Carman <ja...@carmanconsulting.com>.
7.24.100 > 7.24.1
On Tue, Apr 3, 2018 at 5:17 PM Katsuya Tomioka <ka...@gmail.com>
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?
>
> Thanks,
>
> -Katsuya
>