"the specification, which states that the micro part of the
version should be ignored when resolving bundles"
The OSGi specification absolutely does NOT state this. Mainly for the
reasons you have laid out yourself.
Regards,
Neil.
On Mon, 17 Jun 2019 at 23:14, Michael Lipp via osgi-dev <
Hi Tim,
I may have expressed myself badly. Nothing goes wrong, everything works
according to the specification, which states that the micro part of the
version should be ignored when resolving bundles.
My question is whether anybody can explain why the behavior was
specified in such an
Hi
> I may have expressed myself badly. Nothing goes wrong, everything works
> according to the specification, which states that the micro part of the
> version should be ignored when resolving bundles.
….
> If OSGI didn't specify that the micro part should be dropped, then
> everything would
Hi Michael,
I’m afraid that there’s quite a lot of missing information before I could come
to a conclusion about what’s going on. What are your input requirements? Have
you checked that B actually has the version range that you think it does? Are
there two versions of A being deployed? If it’s
Hi,
I have in my repository a bundle A-2.0.1 that exports packages with
version 2.0.1 and a bundle A-2.0.3 that exports these packages with
version 2.0.3. Version A-2.0.3 fixes a bug.
I have a bundle B that imports the packages from A with import
statements "... version=[2.0.3,3)" because the
