Right, but I thought it was a good practice to import the package you export to reduce class spaces. Did I miss something here ?
On Fri, Jun 19, 2009 at 16:09, Karl Pauls<[email protected]> wrote: > 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] > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
