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 wrote:
> Thank you, now the answer is clear.
>
> You can see that the lower version of rbl-osgi (bundle ID 9) has z
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 h
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
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
>
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.wir
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
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
m
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
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: Una
7.24.100 > 7.24.1
On Tue, Apr 3, 2018 at 5:17 PM Katsuya Tomioka
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 ins
> On 3 Apr 2018, at 22:17, Katsuya Tomioka 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.
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 wi
11 matches
Mail list logo
