The seems fairly clear on this. A version like "1.0" is a range from 1.0
to infinity. All things being equal, the resolver is supposed to select
the highest matching version, which is what happens here.
There is some wiggle room since the spec does allow the framework to
choose when a bundle should export or import in this case, but favoring
import seems to make sense to reduce the number of inconsistent class
spaces.
Otherwise I would say the bundle metadata is in error.
-> richard
On 06/19/2009 07:39 AM, Guillaume Nodet wrote:
Let's say we have two bundles
foo-1.0:
Export-Package: a;version="1.0"
Import-Package: a;version="1.0"
foo-2.0:
Export-Package: a;version="2.0"
Import-Package: a;version="2.0"
In felix (trunk), if you install foo-2.0, then foo-1.0, you end up with:
foo-2.0:
Export-Package: a;version="2.0"
foo-1.0:
Import-Package: a;version="2.0"
This really looks ackward (and will mostly lead to failures if the
major versions are not really compatible), though I haven't seen
anything in the core spec to forbid this.
Section 3.7 says that the resolution for foo-1.0 should either choose
an external package (which is what done here) or an internal package.
Equinox seems to handle it using an internal package.
What would you think about changing the resolution algorithm so that
it try to use an internal package instead of an external package if
all the constraints are met ?
