Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
bundlerepository-1.6.6
-
None
-
None
Description
Consider a simple case, package com.stibo.y depends on com.stibo.x, residing in bundle Y and X respectively. X is available in two versions, 1.0.3 and 1.0.4, both exporting com.stibo.x in version 1.0.
Adding bundle Y to a resolver and asking it to resolve, OBR will more or less randomly pick one or the other version of X to satisfy Y's requirement. Which one is chosen depends on the resulting order of resources in RepositoryImpl.m_resourceSet, which in turn depends on the hashCode and the size of the hashSet.
I will attach an example test case demonstrating this. Changing the version numbers in repository.xml you should be able to see it pick the highest version sometimes and sometimes the lowest version.
It seems the OSGI spec is not entirely clear on how to handle this, but it is illogical to leave it depending on the HashSet implementation. In my view, the logical choice would be the bundle with the highest version number.
Notice that ensuring micro-versions of packages is not easy for complex bundles. Also, when bugfixing is done in a released version in a branch, relying on updates to the micro version of exported packages will lead to confusion. Since the API package did not change for the bugfix, the version number of the package should not change.