"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 <
osgi-dev@mail.osgi.org> wrote:
> 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 "unreasonable" way. I tried to explain why I
> consider the behavior "unreasonable": if I author and deliver a bundle
> ("B" in my Mail) and I know that it only works with a specific
> "bug-fixed" version of another bundle ("A-2.0.3") then there is no way
> to enforce that this version is used by my customer.
>
> "Import-Package" with "version=[2.0.3,3)" does not help, because the
> micro part is specified to be ignored. So effectively, requiring
> "version=[2.0.3,3)" is just like requiring "version=[2.0,3)" which makes
> the buggy versions "A-2.0.0" to "A-2.0.2" candidates for the resolution.
>
> Of course, I can state in the release notes of bundle "B" that a user of
> the bundle must take care to not have a version below 2.0.3 in his
> repository. But honestly, if the user happens to already have e.g.
> version A-2.0.1 in his repository due to a requirement that existed
> before adding my bundle to his application, and he adds my bundle and
> everything seems to work fine, how probable is it that he reads the
> release notes when --maybe days later-- something goes wrong because of
> the bug in A-2.0.1?
>
> If OSGI didn't specify that the micro part should be dropped, then
> everything would be fine. Resolution would only be possible if at least
> version 2.0.3 of "A" was available. So, why do we have this
> "unreasonable" specification?
>
> - Michael
>
>
> Am 17.06.19 um 15:17 schrieb Tim Ward:
> > 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
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
