>> Considering this, lowering a lower bound of an Import-Package statement when >> resolving should be acknowledged as a bug. >>
Bnd does not alter the version used when resolving, as this would give “incorrect” answers that don’t resolve. The resolver must use the exact metadata from the bundle manifest, as that it what the framework uses at runtime. What Peter said is that bnd ignores the micro version at *build* time when *generating* your manifest. This is why one of the first things that I asked was “are you sure that your package import is for the micro version you want”. It is possible to make bnd apply micro versions in its generated imports, but it isn’t the default. My guess is that your bundle doesn’t really require what you think it requires. If your bundle is built with a range that doesn’t include micro version numbers in its imports then there is no restriction for the resolver to use in deciding. At that point the bnd resolver heuristics will kick in to *try* to give you the highest version that satisfies your dependencies, but it may not be possible in all cases (this goes back to my well-curated repository argument). If you are able to share the workspace, or even just the repository index + your initial requirements, then we could probably attempt tell you why it’s picking what it’s picking. It’s non-trivial to reverse engineer though. All the best, Tim > On 18 Jun 2019, at 09:54, Michael Lipp via osgi-dev <osgi-dev@mail.osgi.org> > wrote: > > >>> Considering this, lowering a lower bound of an Import-Package statement >>> when resolving should be acknowledged as a bug. >>> >> I beg to differ ... >> >> As said, you can set the consumer/provider policy to your desired strategy. >> > So having default settings in the tool that cause a behavior that does not > comply with the specification should not be considered a bug? > > - Michael > > > >> >> Kind regards, >> >> Peter Kriens >> >>> On 18 Jun 2019, at 10:33, Michael Lipp <m...@mnl.de <mailto:m...@mnl.de>> >>> wrote: >>> >>> >>>> >>>> I expect there are two things at play. First, OSGi specifies things as you >>>> indicate. An import of [1.2.3.qualifier,2) must not select anything lower >>>> than 1.2.3.qualifier. Second, bnd does have heuristics that do drop the >>>> qualifier and micro part in calculating the import ranges from the exports >>>> on the class path. >>> Thanks for the clarification, I think this explains things. >>> >>>> [...] >>>> >>>> Conclusion, the spec is perfect but the implementations apply heuristics >>>> and may have bugs. >>> The specification says (or defines, if you like): "micro - A change that >>> does not affect the API, for example, a typo in a comment or a bug fix in >>> an implementation." It explicitly invites the developer to indicate a bug >>> fix by incrementing the micro part. There's no hint or requirement that he >>> should increment the minor part to reflect a bug fix. I do not find your >>> statement "The definition of the micro version is that it should not make a >>> difference in runtime" to be supported by the spec or the Semantic >>> Versioning Whitepaper. Actually, this interpretation would restrict the >>> usage of the micro part to documentation changes because every bug fix >>> changes the runtime behavior. This is, after all, what it is intended to do. >>> >>> Considering this, lowering a lower bound of an Import-Package statement >>> when resolving should be acknowledged as a bug. >>> >>> - Michael >>> >>> >>> >>>> >>>> Kind regards, >>>> >>>> Peter Kriens >>>> >>>>> On 17 Jun 2019, at 12:14, Michael Lipp via osgi-dev >>>>> <osgi-dev@mail.osgi.org <mailto: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 <mailto:osgi-dev@mail.osgi.org> >>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>>> <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
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
