You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2009/06/19 13:39:04 UTC
Resolution for a bundle exporting and importing the same package
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 ?
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Resolution for a bundle exporting and importing the same package
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 6/19/09 10:28 AM, Guillaume Nodet wrote:
> Right, but I thought it was a good practice to import the package you
> export to reduce class spaces.
> Did I miss something here ?
>
Unfortunately, there is no "always" here, it just depends as I mentioned
in my other email and as mentioned in the FAQ:
http://felix.apache.org/site/apache-felix-osgi-faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages%253F
-> richard
> On Fri, Jun 19, 2009 at 16:09, Karl Pauls<ka...@gmail.com> 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<he...@ungoverned.org> 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<fm...@gmail.com>
>>>> 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<fm...@gmail.com>
>>>>>> 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
>> karlpauls@gmail.com
>>
>>
>
>
>
>
Re: Resolution for a bundle exporting and importing the same package
Posted by Guillaume Nodet <gn...@gmail.com>.
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<ka...@gmail.com> 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<he...@ungoverned.org> 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<fm...@gmail.com>
>>> 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<fm...@gmail.com>
>>>>> 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
> karlpauls@gmail.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Resolution for a bundle exporting and importing the same package
Posted by Karl Pauls <ka...@gmail.com>.
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<he...@ungoverned.org> 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<fm...@gmail.com>
>> 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<fm...@gmail.com>
>>>> 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
karlpauls@gmail.com
Re: Resolution for a bundle exporting and importing the same package
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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<fm...@gmail.com> 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<fm...@gmail.com> 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 ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
>
>
Re: Resolution for a bundle exporting and importing the same package
Posted by Guillaume Nodet <gn...@gmail.com>.
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<fm...@gmail.com> 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<fm...@gmail.com> 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
Re: Resolution for a bundle exporting and importing the same package
Posted by Felix Meschberger <fm...@gmail.com>.
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<fm...@gmail.com> 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 ?
>>>
>>>
>>>
>>>
>>>
>
>
>
Re: Resolution for a bundle exporting and importing the same package
Posted by Guillaume Nodet <gn...@gmail.com>.
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.
On Fri, Jun 19, 2009 at 13:49, Felix Meschberger<fm...@gmail.com> 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
Re: Resolution for a bundle exporting and importing the same package
Posted by Felix Meschberger <fm...@gmail.com>.
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 ?
>
>
>
>
>
Re: Resolution for a bundle exporting and importing the same package
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 6/19/09 10:28 AM, Guillaume Nodet wrote:
> On Fri, Jun 19, 2009 at 15:42, Richard S. Hall<he...@ungoverned.org> wrote:
>
>> On 6/19/09 7:57 AM, Guillaume Nodet wrote:
>>
>>> I think we have two different use case for a bundle importing /
>>> exporting the same package.
>>>
>>> I think the first use case is when you have two different
>>> implementation of a given service. If each service bundles its api,
>>> you'll end up with multiple bundles exporting the same package with
>>> the same version. In such a case, I think it makes sense to choose
>>> to wire to an external bundle.
>>>
>>> The second use case is when you have two different packages exported
>>> with different versions. I think in such a case, felix should choose
>>> the internal package rather than an external.
>>>
>>>
>> Not sure I understand this second case.
>>
>
> This is the use case I expressed in my first email, when you have two
> bundles, each one exporting its own different version of package a.
> This is a usual case when you simply deploy the same library in two
> different versions.
>
> Let's assume that those libraries follow the usual best practices (at
> least those I know about, but correct me if i'm wrong).
> I create a library and use bnd to generate the manifest.
> So I use the following instrutions:
>
> <Import-Package>*</Import-Package>
> <Export-Package>foo;version="1.0"<Export-Package>
> <_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))</_versionpolicy>
>
> This generates the following headers:
> Import-Package: foo;version="[1.0,2.0)"
> Export-Package: foo;version="1.0"
>
To be clear, if you are just creating a library, then you shouldn't
import the packages too...it makes no sense. But if you are a service
impl, for example, packaging the service API with you, then you should
do both.
> If I create a 1.1 version of the same library using the same rules,
> the headers will become:
> Import-Package: foo;version="[1.1,2.0)"
> Export-Package: foo;version="1.1"
>
> Now, it means if i have already installed the 1.1 version of my
> library, i won't be able to use the 1.0 version at all, because the
> package will not be exported.
>
Not precisely correct. Given certain circumstances, you won't be able to
use it.
> I would understand that the bundle importing the library would always
> be wired to the 1.1 version unless it has a specific constraint to
> 1.0, but this constraint could not even by fullfilled because the
> older package is completely hidden.
>
> Maybe the problem come from a misconception, and that importing the
> package you export is actually not a good practice when this package
> is more an implementation package rather than an api package. Or
> maybe the problem is that you need to always import the exact same
> version (without range) that you export.
>
Yes, I think that is it, which is what I am saying above. If you do not
expect there to be multiple implementers of your package or you are just
a library bundle (i.e., no activator) or you do not expect good
backwards compatibility, then you should not import what you export or
do so only with a limited version range.
> In all cases, I'd like the maven bundle plugin to do it the right way
> by default and avoid users running into problems. I guess I just need
> to understand what is the right way ;-)
>
Yes, I agree. Not sure if it can easily tell the difference between
these cases, though.
-> richard
>
>> -> richard
>>
>>
>>> On Fri, Jun 19, 2009 at 13:59, Richard S. Hall<he...@ungoverned.org>
>>> wrote:
>>>
>>>
>>>> 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 ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
>
Re: Resolution for a bundle exporting and importing the same package
Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Jun 19, 2009 at 15:42, Richard S. Hall<he...@ungoverned.org> wrote:
> On 6/19/09 7:57 AM, Guillaume Nodet wrote:
>>
>> I think we have two different use case for a bundle importing /
>> exporting the same package.
>>
>> I think the first use case is when you have two different
>> implementation of a given service. If each service bundles its api,
>> you'll end up with multiple bundles exporting the same package with
>> the same version. In such a case, I think it makes sense to choose
>> to wire to an external bundle.
>>
>> The second use case is when you have two different packages exported
>> with different versions. I think in such a case, felix should choose
>> the internal package rather than an external.
>>
>
> Not sure I understand this second case.
This is the use case I expressed in my first email, when you have two
bundles, each one exporting its own different version of package a.
This is a usual case when you simply deploy the same library in two
different versions.
Let's assume that those libraries follow the usual best practices (at
least those I know about, but correct me if i'm wrong).
I create a library and use bnd to generate the manifest.
So I use the following instrutions:
<Import-Package>*</Import-Package>
<Export-Package>foo;version="1.0"<Export-Package>
<_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))</_versionpolicy>
This generates the following headers:
Import-Package: foo;version="[1.0,2.0)"
Export-Package: foo;version="1.0"
If I create a 1.1 version of the same library using the same rules,
the headers will become:
Import-Package: foo;version="[1.1,2.0)"
Export-Package: foo;version="1.1"
Now, it means if i have already installed the 1.1 version of my
library, i won't be able to use the 1.0 version at all, because the
package will not be exported.
I would understand that the bundle importing the library would always
be wired to the 1.1 version unless it has a specific constraint to
1.0, but this constraint could not even by fullfilled because the
older package is completely hidden.
Maybe the problem come from a misconception, and that importing the
package you export is actually not a good practice when this package
is more an implementation package rather than an api package. Or
maybe the problem is that you need to always import the exact same
version (without range) that you export.
In all cases, I'd like the maven bundle plugin to do it the right way
by default and avoid users running into problems. I guess I just need
to understand what is the right way ;-)
>
> -> richard
>
>> On Fri, Jun 19, 2009 at 13:59, Richard S. Hall<he...@ungoverned.org>
>> wrote:
>>
>>>
>>> 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 ?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Resolution for a bundle exporting and importing the same package
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 6/19/09 7:57 AM, Guillaume Nodet wrote:
> I think we have two different use case for a bundle importing /
> exporting the same package.
>
> I think the first use case is when you have two different
> implementation of a given service. If each service bundles its api,
> you'll end up with multiple bundles exporting the same package with
> the same version. In such a case, I think it makes sense to choose
> to wire to an external bundle.
>
> The second use case is when you have two different packages exported
> with different versions. I think in such a case, felix should choose
> the internal package rather than an external.
>
Not sure I understand this second case.
-> richard
> On Fri, Jun 19, 2009 at 13:59, Richard S. Hall<he...@ungoverned.org> wrote:
>
>> 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 ?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
>
Re: Resolution for a bundle exporting and importing the same package
Posted by Guillaume Nodet <gn...@gmail.com>.
I think we have two different use case for a bundle importing /
exporting the same package.
I think the first use case is when you have two different
implementation of a given service. If each service bundles its api,
you'll end up with multiple bundles exporting the same package with
the same version. In such a case, I think it makes sense to choose
to wire to an external bundle.
The second use case is when you have two different packages exported
with different versions. I think in such a case, felix should choose
the internal package rather than an external.
On Fri, Jun 19, 2009 at 13:59, Richard S. Hall<he...@ungoverned.org> wrote:
> 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 ?
>>
>>
>>
>>
>>
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Resolution for a bundle exporting and importing the same package
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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 ?
>
>
>
>
>
>
Re: Resolution for a bundle exporting and importing the same package
Posted by Guillaume Nodet <gn...@gmail.com>.
Or maybe to avoid this problem, what about enhancing the
maven-bundle-plugin so that when the same package is exported and
imported, a strict import is used.
This would end up with the following by default:
foo-1.0:
Export-Package: a;version="1.0"
Import-Package: a;version="[1.0,1.0]"
foo-2.0:
Export-Package: a;version="2.0"
Import-Package: a;version="[2.0,2.0]"
This is quite difficult to achieve right now if you use the
<_versionpolicy/> config parameter, as all versions will be overriden.
This may require some changes in bnd though...
On Fri, Jun 19, 2009 at 13:39, Guillaume Nodet<gn...@gmail.com> 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 ?
>
>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com