> As for why bnd makes this implementation choice, bear in mind that > import ranges are applied to packages, which in a pure and ideal world > would contain only interfaces and perhaps DTOs, but no implementation > code. What kind of "bugs" could we be talking about in such a package, > other than documentation? Of course the world is not always pure and > ideal which is why the default can be overridden.
But in the real world, every project imports "OSGi-fied" libraries, usually several, and they have bugs and (hopefully) fixes. So it is something to be considered. What good is a tool that works in an ideal world if you need something done in the real world. - Michael > > Neil > > > > On Tue, 18 Jun 2019 at 09:54, Michael Lipp via osgi-dev > <osgi-dev@mail.osgi.org <mailto: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 >>>> >>> >> > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org <mailto: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
