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 possible to share the workspace
then we might be able to bottom out what’s happening.
Also, if 2.0.1 of A is known to be broken then why do you have it in the
repository that you are resolving against? The best defence against “bad”
resolutions is to have a well curated repository. As with many things garbage
in == garbage out.
All the best,
Tim
> On 17 Jun 2019, at 11:14, Michael Lipp via osgi-dev <osgi-dev@mail.osgi.org>
> wrote:
>
> 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 bug fix is crucial for
> the proper working of B.
>
> Clicking on "Resolve" in bndtools, I get a resolution with bundle
> A-2.0.1. I understand that this complies with the specification ("It is
> recommended to ignore the micro part of the version because systems tend
> to become very rigid if they require the latest bug fix to be deployed
> all the time.").
>
> What I don't understand is the rationale. I don't see any drawbacks in
> deploying the latest bug fix. Of course, there's always the risk of
> introducing a new bug with a new version, even if it is supposed to only
> fix a bug in the previous version. But if you're afraid of this, you may
> also not allow imports with version ranges such as "[1.0,2)" (for
> consumers).
>
> In my case, I now have to distribute bundle B with a release note to
> configure the resolution in such a way that only A 2.0.3 and up is used.
> Something that you would expect to happen automatically looking at the
> import statement. And if I want to make sure that the release note is
> not overlooked, the only way seems to be to check the version of "A" at
> run-time in the activation of "B". This is downright ugly.
>
> - Michael
>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
