Hi, Guillaume Nodet schrieb: > Using a version range does not really solve the problem. > > What if you have: > > foo-1.0: > Export-Package: a;version="1.0" > Import-Package: a;version="[1.0,2.0)" > > foo-1.1: > Export-Package: a;version="1.1" > Import-Package: a;version="[1.1,2.0)" > > The exact same problem will happen.
Yes, and is correct for the exact same reason ;-) Maybe the only way to circumvent this is to use [1.0,1.0] as you alredy stipulated. Regards Felix > > On Fri, Jun 19, 2009 at 13:49, Felix Meschberger<[email protected]> wrote: >> Hi, >> >> Guillaume Nodet schrieb: >>> 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 is correct as the resolution specification in Section 3.7, >> Resolution of the core spec (right at the end of that section): >> >> The following list defines the preferences, if multiple choices are >> possible, >> in order of decreasing priority: >> * A resolved exporter must be preferred over an unresolved exporter. >> * An exporter with a higher version is preferred over an exporter with >> a lower version. >> * An exporter with a lower bundle ID is preferred over a bundle with a >> higher ID. >> >> This, since foo-2.0 exports a more recent version, both should import >> that version. >> >> To prvent foo-1.0 from importing a;version="2.0" the import would have >> to be written as a version range excluding version 2.0: >> >> Import-Package: a;version="[1.0,2.0)" >> >> This would effectively result in foo-1.0 and foo-2.0 using incompatible >> classes and not be able to exchange objects from the "a" package. >> >> (But you might want to have this ...) >> >> >> There is catch, tough: Consider foo-1.0 installed and started. Now you >> install and start foo-2.0. Now, foo-1.0 is wired to its own export and >> foo-2.0 is wired to its own export and thus both bundles do *not* share >> the a package.... If you then refresh foo-1.0 (with above import >> declaration) it will wire to foo-2.0's export.... [You might call this a >> corner case, but I am currently fighting such a case looking for a >> solution]. >> >> >> Regards >> Felix >> >>> 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 ? >>> >>> >>> >>> >>> > > >
