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
