It sounds to me as if a bundle that has a package internally and wants to get wired to that one and that one only should just don't import that package, no?
regards, Karl On Fri, Jun 19, 2009 at 3:46 PM, Richard S. Hall<[email protected]> wrote: > On 6/19/09 8:09 AM, Guillaume Nodet wrote: >> >> 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. >> > > It is an easier policy to select the highest matching version to create > fewer class spaces. > > We couldn't have an general approach of favoring the export, because this > would always create a new class space. As a result, we would have to come up > with some nuanced policy of when to favor the internal export over the > import, including how this relates to specified version ranges. And I am > sure no matter what we choose, it won't make everyone happy and we won't be > much better off than we are now. > > Those are my initial thoughts, but I am happy to have the discussion. > > -> richard > > >> 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 ? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >> >> >> >> > -- Karl Pauls [email protected]
