As I said, I know this is correct, but the spec says the resolver has two alternatives. What I want is to discuss why we would not choose the other way, which would *also* be right.
On Fri, Jun 19, 2009 at 14:03, Felix Meschberger<[email protected]> wrote: > 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 ? >>>> >>>> >>>> >>>> >>>> >> >> >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
