As Tim indicates we need more information. 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.
When bnd builds a bundle it calculates the import range based on the package it was compiled against. Bnd finds the version looking at packageinfo, package-info.class, and the manifest. It then checks if that package is 'provided' or 'consumed' by the bundle, and from this information it calculates the range. The base version does indeed drop the qualifier and the micro version. I hope dropping the qualifier sounds logical to you? If you do not drop the qualifier you always need a fresh bundle with whatever you do. This is hell. Since the micro version in a semantic version cannot make a difference it is logically safe to drop that one as well. The definition of the micro version is that it should not make a difference in runtime. Having a bug fix in a micro version is just plain wrong. Why have a spec when a tool cannot rely on its semantics? At the time when we're starting with this this heuristic made things a lot easier to work with. Although the micro version is less volatile than the qualifier, our experience was that you ended up in a similar hell that the most minute change required everything to change. Especially since we did not have a resolver at that time. We've got almost 18 years of experience with this model and I think it has worked quite well so far. However, with the resolver going mainstream in the last few years maybe we need to revisit it. If you do not agree with the heuristic you can set the policy for the provider and consumer import range yourself. See https://bnd.bndtools.org/instructions/provider_policy.html <https://bnd.bndtools.org/instructions/provider_policy.html> Personally I would not do this because your then trying to fix the original error (a bug fix in a micro version) in the wrong place. Although this can be a quick fix, in my experience these hacks tend to exponentially increase the complexity of the build over time since you can no longer rely on the established rules, forcing you to make specials everywhere over time. In your case you or someone in your team did not apply the rules for semantic versioning. That happens, especially when you have to rely on external software. In that case you can manually apply the import range in the manifest/bnd.bnd file. This exact import range must be obeyed by the resolver. That said, if 2.0.1 and 2.0.3 are available then it would be nice if the resolver would prefer the highest possible version as a heuristic. In bnd we compile against the lowest version to keep the base as low as possible but in runtime we prefer the highest allowed version. I assumed that the bnd resolver had this behavior since we order the resources. Maybe there were other constraints that made 2.0.3 less attractive than 2.0.1. To know that we need to know more about the exact setup. Conclusion, the spec is perfect but the implementations apply heuristics and may have bugs. Kind regards, Peter Kriens > On 17 Jun 2019, at 12: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
