You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by An...@sybase.com on 2009/12/16 01:54:03 UTC
Less restrictive conflict resolution for fragment imports
Hi,
I found that Felix is validating the compatibility of host vs. fragment
imports by ensuring that in case host and fragment are importing the same
package, they should use the exactly same version (range). I believe that
this is a little too restrictive and Felix should also allow the host
bundle to be more restrictive on the version range than the fragment. This
way, it is still guaranteed that the fragment will run with using the
version range from the host bundle (which is a subset of the fragment
version range in this case).
I just ran into this problem when trying to use the Hibernate +
Annotations bundles packaged by SpringSource. Hibernate Annotations is a
fragment bundle, hosted by the Hibernate bundle. Hibernate imports
org.dom4j;version="[1.6.1, 1.7.0)" whereas the fragment imports
org.dom4j;version="[1.6.1, 2.0.0)" and the current implementation does not
allow this fragment to be linked to its host.
What do you think?
Thanks
Andreas
Re: Less restrictive conflict resolution for fragment imports
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 12/16/09 11:44, Angelo vd Sijpt wrote:
> The spec is sort of vague about this, it just states that the versions
> "should not conflict", and if they do, the fragment bundle should not
> resolve.
> Also, the spec does not say anything about the _actual_ version that the
> host imports, it just states that the specifiers should not conflict. This
> is a more restrictive approach, which might cause a fragment not to resolve,
> while the actual situation would allow it to.
>
Yeah, this is under spec'ed and depending on any behavior here at all is
equivalent to depending on framework-specific behavior.
-> richard
> I agree that an intersection of versions is probably the best interpretation
> of this.
>
> Angelo
>
> On Wed, Dec 16, 2009 at 5:30 PM, Richard S. Hall<he...@ungoverned.org>wrote:
>
>
>> What I was planning on doing is taking the intersection, which would be the
>> highest floor and the lowest ceiling of each overlapping version range...and
>> of course, if there is no intersection, then they are in conflict and the
>> fragment would be thrown out.
>>
>> -> richard
>>
>>
>> On 12/16/09 11:13, Andreas.Schlosser@sybase.com wrote:
>>
>>
>>> Guo,
>>>
>>> I think your algorithm is not 100% correct. The host version boundaries
>>> must lie within the fragment version boundaries. So, looking at your
>>> example:
>>>
>>>
>>>
>>>
>>>> Host version [2.0.0,3.0.0)
>>>>
>>>>
>>>>
>>>
>>>
>>>> Fail fragment versions [1.0.0], [1.0.0,2.0.0), [3.0.0]
>>>>
>>>>
>>>>
>>> Fails, since version lies completely outside host version boundaries
>>>
>>>
>>>
>>>
>>>> Pass fragment versions
>>>> [1.0.0,5.0.0),
>>>>
>>>>
>>>>
>>> Passes, since host version lies within these boundaries
>>>
>>>
>>>
>>>
>>>> [2.5.0,2.9.0)
>>>>
>>>>
>>>>
>>> Fails, since host version lies outside boundaries. E.g., when host is
>>> importing 2.1.0 this would cause fragment to fail.
>>>
>>> Thanks,
>>> Andreas
>>>
>>>
>>> Guo Du<mr...@gmail.com> wrote on 12/16/2009 02:25:50 AM:
>>>
>>>
>>>
>>>
>>>> On Wed, Dec 16, 2009 at 12:54 AM,<An...@sybase.com> wrote:
>>>>
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> I found that Felix is validating the compatibility of host vs.
>>>>>
>>>>>
>>>>>
>>>> fragment
>>>>
>>>
>>>
>>>> imports by ensuring that in case host and fragment are importing the
>>>>
>>>>>
>>>>>
>>>> same
>>>>
>>>
>>>
>>>> package, they should use the exactly same version (range). I believe
>>>>
>>>>>
>>>>>
>>>> that
>>>>
>>>
>>>
>>>> this is a little too restrictive and Felix should also allow the host
>>>>
>>>>> bundle to be more restrictive on the version range than the fragment.
>>>>>
>>>>>
>>>>>
>>>> This
>>>>
>>>
>>>
>>>> way, it is still guaranteed that the fragment will run with using the
>>>>
>>>>> version range from the host bundle (which is a subset of the fragment
>>>>> version range in this case).
>>>>>
>>>>> I just ran into this problem when trying to use the Hibernate +
>>>>> Annotations bundles packaged by SpringSource. Hibernate Annotations is
>>>>>
>>>>>
>>>>>
>>>> a
>>>>
>>>
>>>
>>>> fragment bundle, hosted by the Hibernate bundle. Hibernate imports
>>>>
>>>>> org.dom4j;version="[1.6.1, 1.7.0)" whereas the fragment imports
>>>>> org.dom4j;version="[1.6.1, 2.0.0)" and the current implementation does
>>>>>
>>>>>
>>>>>
>>>> not
>>>>
>>>
>>>
>>>> allow this fragment to be linked to its host.
>>>>
>>>>> What do you think?
>>>>>
>>>>>
>>>>>
>>>> +1
>>>>
>>>> I have this problem with spring-osgi-extender as well. For fragment,
>>>> we may enable the fragment when there are common set between host
>>>> version and fragment version.
>>>>
>>>> Host version [2.0.0,3.0.0)
>>>> Fail fragment versions [1.0.0], [1.0.0,2.0.0), [3.0.0]
>>>> Pass fragment versions [1.0.0,5.0.0), [2.5.0,2.9.0)
>>>>
>>>> Any drawback to this approach?
>>>>
>>>> -Guo
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
Re: Less restrictive conflict resolution for fragment imports
Posted by Angelo vd Sijpt <an...@gmail.com>.
The spec is sort of vague about this, it just states that the versions
"should not conflict", and if they do, the fragment bundle should not
resolve.
Also, the spec does not say anything about the _actual_ version that the
host imports, it just states that the specifiers should not conflict. This
is a more restrictive approach, which might cause a fragment not to resolve,
while the actual situation would allow it to.
I agree that an intersection of versions is probably the best interpretation
of this.
Angelo
On Wed, Dec 16, 2009 at 5:30 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> What I was planning on doing is taking the intersection, which would be the
> highest floor and the lowest ceiling of each overlapping version range...and
> of course, if there is no intersection, then they are in conflict and the
> fragment would be thrown out.
>
> -> richard
>
>
> On 12/16/09 11:13, Andreas.Schlosser@sybase.com wrote:
>
>> Guo,
>>
>> I think your algorithm is not 100% correct. The host version boundaries
>> must lie within the fragment version boundaries. So, looking at your
>> example:
>>
>>
>>
>>> Host version [2.0.0,3.0.0)
>>>
>>>
>>
>>
>>> Fail fragment versions [1.0.0], [1.0.0,2.0.0), [3.0.0]
>>>
>>>
>> Fails, since version lies completely outside host version boundaries
>>
>>
>>
>>> Pass fragment versions
>>> [1.0.0,5.0.0),
>>>
>>>
>> Passes, since host version lies within these boundaries
>>
>>
>>
>>> [2.5.0,2.9.0)
>>>
>>>
>> Fails, since host version lies outside boundaries. E.g., when host is
>> importing 2.1.0 this would cause fragment to fail.
>>
>> Thanks,
>> Andreas
>>
>>
>> Guo Du<mr...@gmail.com> wrote on 12/16/2009 02:25:50 AM:
>>
>>
>>
>>> On Wed, Dec 16, 2009 at 12:54 AM,<An...@sybase.com> wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>> I found that Felix is validating the compatibility of host vs.
>>>>
>>>>
>>> fragment
>>
>>
>>> imports by ensuring that in case host and fragment are importing the
>>>>
>>>>
>>> same
>>
>>
>>> package, they should use the exactly same version (range). I believe
>>>>
>>>>
>>> that
>>
>>
>>> this is a little too restrictive and Felix should also allow the host
>>>> bundle to be more restrictive on the version range than the fragment.
>>>>
>>>>
>>> This
>>
>>
>>> way, it is still guaranteed that the fragment will run with using the
>>>> version range from the host bundle (which is a subset of the fragment
>>>> version range in this case).
>>>>
>>>> I just ran into this problem when trying to use the Hibernate +
>>>> Annotations bundles packaged by SpringSource. Hibernate Annotations is
>>>>
>>>>
>>> a
>>
>>
>>> fragment bundle, hosted by the Hibernate bundle. Hibernate imports
>>>> org.dom4j;version="[1.6.1, 1.7.0)" whereas the fragment imports
>>>> org.dom4j;version="[1.6.1, 2.0.0)" and the current implementation does
>>>>
>>>>
>>> not
>>
>>
>>> allow this fragment to be linked to its host.
>>>>
>>>> What do you think?
>>>>
>>>>
>>> +1
>>>
>>> I have this problem with spring-osgi-extender as well. For fragment,
>>> we may enable the fragment when there are common set between host
>>> version and fragment version.
>>>
>>> Host version [2.0.0,3.0.0)
>>> Fail fragment versions [1.0.0], [1.0.0,2.0.0), [3.0.0]
>>> Pass fragment versions [1.0.0,5.0.0), [2.5.0,2.9.0)
>>>
>>> Any drawback to this approach?
>>>
>>> -Guo
>>>
>>>
>>>
>>
>>
>
Re: Less restrictive conflict resolution for fragment imports
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 12/16/09 11:48, Andreas.Schlosser@sybase.com wrote:
> Richard,
>
> this could also work, but will add more complexity to it. You may run into
> situations were you need to randomly abandon one fragment:
>
> Host imports version [1.0.0,2.0.0), fragment 1 imports [1.0.0,1.5.0),
> fragment 2 imports [1.5.0,2.0.0)
>
> In my approach, both fragments would be exluded, in your approach you have
> to find a tie breaker to decide on which fragment to include.
>
The tie breaker is bundle ID, which I think is specified by the spec.
-> richard
> With my approach, statically determining the valid version range by
> looking at the host bundle, you'd keep the control over valid versions
> with the host bundle and everybody using it can be sure that the host and
> all possibly existing fragments will run when obeying the host version
> range (so, when using a consistent set of bundles you can be sure that you
> can add any fragment you want without updating other bundles). When
> dynamically determining the version range by looking at fragments as well,
> you'd take away this guarantee. It may happen that a consistent set of
> bundles gets inconsistent out of a sudden because of a fragment with too
> restrictive import versions (meaning the fragment does not work).
>
> The dynamic approach obviously has the advantage to be more flexible, but
> I think it should rather be the responsibility of a fragment developer to
> adhere to the version ranges of the host bundle than the responsibility of
> the user of a host bundle to comply to (more restrictive) version ranges
> in fragments he'd like to use.
>
> Maybe it would be interesting to look into how Equinox is doing it,
> unfortunately I don't know. Can anybody help?
>
> Thanks
> Andreas
>
>
> "Richard S. Hall"<he...@ungoverned.org> wrote on 12/16/2009 08:30:10 AM:
>
>
>> What I was planning on doing is taking the intersection, which would be
>> the highest floor and the lowest ceiling of each overlapping version
>> range...and of course, if there is no intersection, then they are in
>> conflict and the fragment would be thrown out.
>>
>> -> richard
>>
>> On 12/16/09 11:13, Andreas.Schlosser@sybase.com wrote:
>>
>>> Guo,
>>>
>>> I think your algorithm is not 100% correct. The host version
>>>
> boundaries
>
>>> must lie within the fragment version boundaries. So, looking at your
>>> example:
>>>
>>>
>>>
>>>> Host version [2.0.0,3.0.0)
>>>>
>>>>
>>>
>>>> Fail fragment versions [1.0.0], [1.0.0,2.0.0), [3.0.0]
>>>>
>>>>
>>> Fails, since version lies completely outside host version boundaries
>>>
>>>
>>>
>>>> Pass fragment versions
>>>> [1.0.0,5.0.0),
>>>>
>>>>
>>> Passes, since host version lies within these boundaries
>>>
>>>
>>>
>>>> [2.5.0,2.9.0)
>>>>
>>>>
>>> Fails, since host version lies outside boundaries. E.g., when host is
>>> importing 2.1.0 this would cause fragment to fail.
>>>
>>> Thanks,
>>> Andreas
>>>
>>>
>>> Guo Du<mr...@gmail.com> wrote on 12/16/2009 02:25:50 AM:
>>>
>>>
>>>
>>>> On Wed, Dec 16, 2009 at 12:54 AM,<An...@sybase.com>
>>>>
> wrote:
>
>>>>
>>>>> Hi,
>>>>>
>>>>> I found that Felix is validating the compatibility of host vs.
>>>>>
>>>>>
>>> fragment
>>>
>>>
>>>>> imports by ensuring that in case host and fragment are importing the
>>>>>
>>>>>
>>> same
>>>
>>>
>>>>> package, they should use the exactly same version (range). I believe
>>>>>
>>>>>
>>> that
>>>
>>>
>>>>> this is a little too restrictive and Felix should also allow the
>>>>>
> host
>
>>>>> bundle to be more restrictive on the version range than the
>>>>>
> fragment.
>
>>>>>
>>> This
>>>
>>>
>>>>> way, it is still guaranteed that the fragment will run with using
>>>>>
> the
>
>>>>> version range from the host bundle (which is a subset of the
>>>>>
> fragment
>
>>>>> version range in this case).
>>>>>
>>>>> I just ran into this problem when trying to use the Hibernate +
>>>>> Annotations bundles packaged by SpringSource. Hibernate Annotations
>>>>>
> is
>
>>>>>
>>> a
>>>
>>>
>>>>> fragment bundle, hosted by the Hibernate bundle. Hibernate imports
>>>>> org.dom4j;version="[1.6.1, 1.7.0)" whereas the fragment imports
>>>>> org.dom4j;version="[1.6.1, 2.0.0)" and the current implementation
>>>>>
> does
>
>>>>>
>>> not
>>>
>>>
>>>>> allow this fragment to be linked to its host.
>>>>>
>>>>> What do you think?
>>>>>
>>>>>
>>>> +1
>>>>
>>>> I have this problem with spring-osgi-extender as well. For fragment,
>>>> we may enable the fragment when there are common set between host
>>>> version and fragment version.
>>>>
>>>> Host version [2.0.0,3.0.0)
>>>> Fail fragment versions [1.0.0], [1.0.0,2.0.0), [3.0.0]
>>>> Pass fragment versions [1.0.0,5.0.0), [2.5.0,2.9.0)
>>>>
>>>> Any drawback to this approach?
>>>>
>>>> -Guo
>>>>
>>>>
>>>>
>>>
>>
>
Re: Less restrictive conflict resolution for fragment imports
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 2/1/10 11:25, Chris Custine wrote:
> I just wanted to also confirm that the Hibernate bundles all seem to resolve
> and work properly now with this fix. We have several issues logged against
> Karaf as well as ServiceMix regarding this and I have confirmed with several
> of those users that the fix resolves all of their remaining issues. I think
> we will finally be able to close the Hibernate fragment saga! Thanks a lot
> Richard for getting this in for the next release.
>
> I would like to get this framework release into the next Karaf release
> (pending this fix), so I would be quite happy to cut this release ASAP if
> everyone else is busy. Let me know...
>
We are planning a release this week.
-> richard
> Thanks,
> Chris
> --
> Chris Custine
> FUSESource :: http://fusesource.com
> My Blog :: http://blog.organicelement.com
> Apache ServiceMix :: http://servicemix.apache.org
> Apache Felix :: http://felix.apache.org
> Apache Directory Server :: http://directory.apache.org
>
>
> On Wed, Jan 27, 2010 at 1:01 PM, Richard S. Hall<he...@ungoverned.org>wrote:
>
>
>> On 1/27/10 14:25, Andreas.Schlosser@sybase.com wrote:
>>
>>
>>> Great, thanks Richard. The Hibernate Annotations stuff is wired properly
>>> now for me!
>>>
>>>
>>>
>> Good to hear. We're planning a Felix 2.0.3 release shortly which will
>> include this fix for the short term. Long term, I am trying to completely
>> re-implement Felix' resolver to address some performance issues (and some
>> other items on my agenda), so I expect fragment merging to happen completely
>> differently in Felix 3.0, but hopefully even more leniently.
>>
>> -> richard
>>
>>
>> Thanks again,
>>
>>> Andreas
>>>
>>>
>>>
>>>
>>>
>>> "Richard S. Hall"<he...@ungoverned.org>
>>> 01/22/2010 12:19 PM
>>> Please respond to
>>> dev@felix.apache.org
>>>
>>>
>>> To
>>> dev@felix.apache.org
>>> cc
>>>
>>> Subject
>>> Re: Less restrictive conflict resolution for fragment imports
>>>
>>>
>>>
>>>
>>>
>>>
>>> I just committed a patch to try to make fragment merging less
>>> restrictive by calculating version range intersections for merged
>>> requirements. It still requires that everything else be the same pretty
>>> much, only versions are allowed to vary.
>>>
>>> Could someone please test to see if this works for them. I deployed new
>>> snapshots or you can build from trunk.
>>>
>>> Thanks.
>>>
>>> -> richard
>>>
>>> On 12/17/09 9:44, Richard S. Hall wrote:
>>>
>>>
>>>
>>>> On 12/17/09 9:42, Richard S. Hall wrote:
>>>>
>>>>
>>>>
>>>>> On 12/17/09 8:27, Stuart McCulloch wrote:
>>>>>
>>>>>
>>>>>
>>>>>> 2009/12/17 Guo Du<mr...@gmail.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Wed, Dec 16, 2009 at 5:37 PM, Stuart McCulloch<mc...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> So +1 to trying the intersection approach.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Intersection ONLY is not safe for the case:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Host version [2.0.0,3.0.0)
>>>>>>>> [2.5.0,2.9.0)
>>>>>>>> Fails, when host is importing 2.1.0 this would cause fragment to
>>>>>>>> fail.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> depends when the intersection was made - if it was done before the
>>>>>>>
>>>>>>
>>>>>>
>>>>> host
>>>>>
>>>
>>>
>>>> resolved
>>>>
>>>>>> then the host's import range would shrink to the intersection:
>>>>>> [2.5.0,2.9.0)
>>>>>> and the
>>>>>> host plus fragment would not be in conflict.
>>>>>>
>>>>>> now if you're attaching the fragment to an already resolved host then
>>>>>>
>>>>>>
>>>>>>
>>>>> I
>>>>>
>>>
>>>
>>>> believe the
>>>>
>>>>>> resolver would look at the existing wires, not the original range -
>>>>>> so if
>>>>>> the host was
>>>>>> already wired to 2.1.0 then the fragment wouldn't be able to attach
>>>>>> dynamically
>>>>>>
>>>>>> but then this is still correct (afaik) in that you can't dynamically
>>>>>> attach
>>>>>> a fragment
>>>>>> that conflicts with the resolved host (btw, do we support dynamic
>>>>>> attachment?)
>>>>>>
>>>>>>
>>>>>>
>>>>> No, we don't.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> We may have following condition to enable fragment:
>>>>>>
>>>>>>> 1. exact version match or
>>>>>>> 2. host version range inside all fragments version or
>>>>>>> 3. all fragments and host share intersection + dynamic verify the
>>>>>>> actual imported version is inside intersection
>>>>>>> (p.s. I am not sure "dynamic verify the actual imported version is
>>>>>>> inside intersection" is viable or not. If not, we could do at least
>>>>>>> step 2 which will help both Andreas's and FELIX-1919 case )
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> these still fall under 'intersection' imho (ie. the intersection
>>>>>>
>>>>>>
>>>>>>
>>>>> should
>>>>>
>>>
>>>
>>>> apply to the
>>>>
>>>>>> host and fragment) but let's see what Richard's algorithm actually
>>>>>> looks
>>>>>> like :)
>>>>>>
>>>>>>
>>>>>>
>>>>> The intersection approach will create a new version range each time a
>>>>> fragment is added and the next fragment will be compared against that
>>>>> range in bundle ID order. I don't think this will allow for any valid
>>>>> cases since we are always making the allowed version range more narror.
>>>>>
>>>>>
>>>>>
>>>> Should say "any invalid cases"..."more narrow"...
>>>>
>>>> -> richard
>>>>
>>>>
>>>>
>>>>
>>>>> -> richard
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>> -Guo
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>
>>>
>>>
>>
>
Re: Less restrictive conflict resolution for fragment imports
Posted by Chris Custine <ch...@gmail.com>.
I just wanted to also confirm that the Hibernate bundles all seem to resolve
and work properly now with this fix. We have several issues logged against
Karaf as well as ServiceMix regarding this and I have confirmed with several
of those users that the fix resolves all of their remaining issues. I think
we will finally be able to close the Hibernate fragment saga! Thanks a lot
Richard for getting this in for the next release.
I would like to get this framework release into the next Karaf release
(pending this fix), so I would be quite happy to cut this release ASAP if
everyone else is busy. Let me know...
Thanks,
Chris
--
Chris Custine
FUSESource :: http://fusesource.com
My Blog :: http://blog.organicelement.com
Apache ServiceMix :: http://servicemix.apache.org
Apache Felix :: http://felix.apache.org
Apache Directory Server :: http://directory.apache.org
On Wed, Jan 27, 2010 at 1:01 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> On 1/27/10 14:25, Andreas.Schlosser@sybase.com wrote:
>
>> Great, thanks Richard. The Hibernate Annotations stuff is wired properly
>> now for me!
>>
>>
>
> Good to hear. We're planning a Felix 2.0.3 release shortly which will
> include this fix for the short term. Long term, I am trying to completely
> re-implement Felix' resolver to address some performance issues (and some
> other items on my agenda), so I expect fragment merging to happen completely
> differently in Felix 3.0, but hopefully even more leniently.
>
> -> richard
>
>
> Thanks again,
>> Andreas
>>
>>
>>
>>
>>
>> "Richard S. Hall"<he...@ungoverned.org>
>> 01/22/2010 12:19 PM
>> Please respond to
>> dev@felix.apache.org
>>
>>
>> To
>> dev@felix.apache.org
>> cc
>>
>> Subject
>> Re: Less restrictive conflict resolution for fragment imports
>>
>>
>>
>>
>>
>>
>> I just committed a patch to try to make fragment merging less
>> restrictive by calculating version range intersections for merged
>> requirements. It still requires that everything else be the same pretty
>> much, only versions are allowed to vary.
>>
>> Could someone please test to see if this works for them. I deployed new
>> snapshots or you can build from trunk.
>>
>> Thanks.
>>
>> -> richard
>>
>> On 12/17/09 9:44, Richard S. Hall wrote:
>>
>>
>>> On 12/17/09 9:42, Richard S. Hall wrote:
>>>
>>>
>>>> On 12/17/09 8:27, Stuart McCulloch wrote:
>>>>
>>>>
>>>>> 2009/12/17 Guo Du<mr...@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>>> On Wed, Dec 16, 2009 at 5:37 PM, Stuart McCulloch<mc...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>> So +1 to trying the intersection approach.
>>>>>>>
>>>>>>>
>>>>>> Intersection ONLY is not safe for the case:
>>>>>>
>>>>>>
>>>>>>> Host version [2.0.0,3.0.0)
>>>>>>> [2.5.0,2.9.0)
>>>>>>> Fails, when host is importing 2.1.0 this would cause fragment to
>>>>>>> fail.
>>>>>>>
>>>>>>>
>>>>>> depends when the intersection was made - if it was done before the
>>>>>
>>>>>
>>>> host
>>
>>
>>> resolved
>>>>> then the host's import range would shrink to the intersection:
>>>>> [2.5.0,2.9.0)
>>>>> and the
>>>>> host plus fragment would not be in conflict.
>>>>>
>>>>> now if you're attaching the fragment to an already resolved host then
>>>>>
>>>>>
>>>> I
>>
>>
>>> believe the
>>>>> resolver would look at the existing wires, not the original range -
>>>>> so if
>>>>> the host was
>>>>> already wired to 2.1.0 then the fragment wouldn't be able to attach
>>>>> dynamically
>>>>>
>>>>> but then this is still correct (afaik) in that you can't dynamically
>>>>> attach
>>>>> a fragment
>>>>> that conflicts with the resolved host (btw, do we support dynamic
>>>>> attachment?)
>>>>>
>>>>>
>>>> No, we don't.
>>>>
>>>>
>>>>
>>>>> We may have following condition to enable fragment:
>>>>>> 1. exact version match or
>>>>>> 2. host version range inside all fragments version or
>>>>>> 3. all fragments and host share intersection + dynamic verify the
>>>>>> actual imported version is inside intersection
>>>>>> (p.s. I am not sure "dynamic verify the actual imported version is
>>>>>> inside intersection" is viable or not. If not, we could do at least
>>>>>> step 2 which will help both Andreas's and FELIX-1919 case )
>>>>>>
>>>>>>
>>>>>>
>>>>> these still fall under 'intersection' imho (ie. the intersection
>>>>>
>>>>>
>>>> should
>>
>>
>>> apply to the
>>>>> host and fragment) but let's see what Richard's algorithm actually
>>>>> looks
>>>>> like :)
>>>>>
>>>>>
>>>> The intersection approach will create a new version range each time a
>>>> fragment is added and the next fragment will be compared against that
>>>> range in bundle ID order. I don't think this will allow for any valid
>>>> cases since we are always making the allowed version range more narror.
>>>>
>>>>
>>> Should say "any invalid cases"..."more narrow"...
>>>
>>> -> richard
>>>
>>>
>>>
>>>> -> richard
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>> -Guo
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>
>>
>>
>
Re: Less restrictive conflict resolution for fragment imports
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 1/27/10 14:25, Andreas.Schlosser@sybase.com wrote:
> Great, thanks Richard. The Hibernate Annotations stuff is wired properly
> now for me!
>
Good to hear. We're planning a Felix 2.0.3 release shortly which will
include this fix for the short term. Long term, I am trying to
completely re-implement Felix' resolver to address some performance
issues (and some other items on my agenda), so I expect fragment merging
to happen completely differently in Felix 3.0, but hopefully even more
leniently.
-> richard
> Thanks again,
> Andreas
>
>
>
>
>
> "Richard S. Hall"<he...@ungoverned.org>
> 01/22/2010 12:19 PM
> Please respond to
> dev@felix.apache.org
>
>
> To
> dev@felix.apache.org
> cc
>
> Subject
> Re: Less restrictive conflict resolution for fragment imports
>
>
>
>
>
>
> I just committed a patch to try to make fragment merging less
> restrictive by calculating version range intersections for merged
> requirements. It still requires that everything else be the same pretty
> much, only versions are allowed to vary.
>
> Could someone please test to see if this works for them. I deployed new
> snapshots or you can build from trunk.
>
> Thanks.
>
> -> richard
>
> On 12/17/09 9:44, Richard S. Hall wrote:
>
>> On 12/17/09 9:42, Richard S. Hall wrote:
>>
>>> On 12/17/09 8:27, Stuart McCulloch wrote:
>>>
>>>> 2009/12/17 Guo Du<mr...@gmail.com>
>>>>
>>>>
>>>>> On Wed, Dec 16, 2009 at 5:37 PM, Stuart McCulloch<mc...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> So +1 to trying the intersection approach.
>>>>>>
>>>>> Intersection ONLY is not safe for the case:
>>>>>
>>>>>> Host version [2.0.0,3.0.0)
>>>>>> [2.5.0,2.9.0)
>>>>>> Fails, when host is importing 2.1.0 this would cause fragment to
>>>>>> fail.
>>>>>>
>>>> depends when the intersection was made - if it was done before the
>>>>
> host
>
>>>> resolved
>>>> then the host's import range would shrink to the intersection:
>>>> [2.5.0,2.9.0)
>>>> and the
>>>> host plus fragment would not be in conflict.
>>>>
>>>> now if you're attaching the fragment to an already resolved host then
>>>>
> I
>
>>>> believe the
>>>> resolver would look at the existing wires, not the original range -
>>>> so if
>>>> the host was
>>>> already wired to 2.1.0 then the fragment wouldn't be able to attach
>>>> dynamically
>>>>
>>>> but then this is still correct (afaik) in that you can't dynamically
>>>> attach
>>>> a fragment
>>>> that conflicts with the resolved host (btw, do we support dynamic
>>>> attachment?)
>>>>
>>> No, we don't.
>>>
>>>
>>>>> We may have following condition to enable fragment:
>>>>> 1. exact version match or
>>>>> 2. host version range inside all fragments version or
>>>>> 3. all fragments and host share intersection + dynamic verify the
>>>>> actual imported version is inside intersection
>>>>> (p.s. I am not sure "dynamic verify the actual imported version is
>>>>> inside intersection" is viable or not. If not, we could do at least
>>>>> step 2 which will help both Andreas's and FELIX-1919 case )
>>>>>
>>>>>
>>>> these still fall under 'intersection' imho (ie. the intersection
>>>>
> should
>
>>>> apply to the
>>>> host and fragment) but let's see what Richard's algorithm actually
>>>> looks
>>>> like :)
>>>>
>>> The intersection approach will create a new version range each time a
>>> fragment is added and the next fragment will be compared against that
>>> range in bundle ID order. I don't think this will allow for any valid
>>> cases since we are always making the allowed version range more narror.
>>>
>> Should say "any invalid cases"..."more narrow"...
>>
>> -> richard
>>
>>
>>> -> richard
>>>
>>>
>>>>
>>>>> -Guo
>>>>>
>>>>>
>
>
>
Re: Less restrictive conflict resolution for fragment imports
Posted by An...@sybase.com.
Great, thanks Richard. The Hibernate Annotations stuff is wired properly
now for me!
Thanks again,
Andreas
"Richard S. Hall" <he...@ungoverned.org>
01/22/2010 12:19 PM
Please respond to
dev@felix.apache.org
To
dev@felix.apache.org
cc
Subject
Re: Less restrictive conflict resolution for fragment imports
I just committed a patch to try to make fragment merging less
restrictive by calculating version range intersections for merged
requirements. It still requires that everything else be the same pretty
much, only versions are allowed to vary.
Could someone please test to see if this works for them. I deployed new
snapshots or you can build from trunk.
Thanks.
-> richard
On 12/17/09 9:44, Richard S. Hall wrote:
> On 12/17/09 9:42, Richard S. Hall wrote:
>> On 12/17/09 8:27, Stuart McCulloch wrote:
>>> 2009/12/17 Guo Du<mr...@gmail.com>
>>>
>>>> On Wed, Dec 16, 2009 at 5:37 PM, Stuart McCulloch<mc...@gmail.com>
>>>> wrote:
>>>>> So +1 to trying the intersection approach.
>>>> Intersection ONLY is not safe for the case:
>>>>> Host version [2.0.0,3.0.0)
>>>>> [2.5.0,2.9.0)
>>>>> Fails, when host is importing 2.1.0 this would cause fragment to
>>>>> fail.
>>> depends when the intersection was made - if it was done before the
host
>>> resolved
>>> then the host's import range would shrink to the intersection:
>>> [2.5.0,2.9.0)
>>> and the
>>> host plus fragment would not be in conflict.
>>>
>>> now if you're attaching the fragment to an already resolved host then
I
>>> believe the
>>> resolver would look at the existing wires, not the original range -
>>> so if
>>> the host was
>>> already wired to 2.1.0 then the fragment wouldn't be able to attach
>>> dynamically
>>>
>>> but then this is still correct (afaik) in that you can't dynamically
>>> attach
>>> a fragment
>>> that conflicts with the resolved host (btw, do we support dynamic
>>> attachment?)
>>
>> No, we don't.
>>
>>>> We may have following condition to enable fragment:
>>>> 1. exact version match or
>>>> 2. host version range inside all fragments version or
>>>> 3. all fragments and host share intersection + dynamic verify the
>>>> actual imported version is inside intersection
>>>> (p.s. I am not sure "dynamic verify the actual imported version is
>>>> inside intersection" is viable or not. If not, we could do at least
>>>> step 2 which will help both Andreas's and FELIX-1919 case )
>>>>
>>> these still fall under 'intersection' imho (ie. the intersection
should
>>> apply to the
>>> host and fragment) but let's see what Richard's algorithm actually
>>> looks
>>> like :)
>>
>> The intersection approach will create a new version range each time a
>> fragment is added and the next fragment will be compared against that
>> range in bundle ID order. I don't think this will allow for any valid
>> cases since we are always making the allowed version range more narror.
>
> Should say "any invalid cases"..."more narrow"...
>
> -> richard
>
>>
>> -> richard
>>
>>>
>>>> -Guo
>>>>
Re: Less restrictive conflict resolution for fragment imports
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I just committed a patch to try to make fragment merging less
restrictive by calculating version range intersections for merged
requirements. It still requires that everything else be the same pretty
much, only versions are allowed to vary.
Could someone please test to see if this works for them. I deployed new
snapshots or you can build from trunk.
Thanks.
-> richard
On 12/17/09 9:44, Richard S. Hall wrote:
> On 12/17/09 9:42, Richard S. Hall wrote:
>> On 12/17/09 8:27, Stuart McCulloch wrote:
>>> 2009/12/17 Guo Du<mr...@gmail.com>
>>>
>>>> On Wed, Dec 16, 2009 at 5:37 PM, Stuart McCulloch<mc...@gmail.com>
>>>> wrote:
>>>>> So +1 to trying the intersection approach.
>>>> Intersection ONLY is not safe for the case:
>>>>> Host version [2.0.0,3.0.0)
>>>>> [2.5.0,2.9.0)
>>>>> Fails, when host is importing 2.1.0 this would cause fragment to
>>>>> fail.
>>> depends when the intersection was made - if it was done before the host
>>> resolved
>>> then the host's import range would shrink to the intersection:
>>> [2.5.0,2.9.0)
>>> and the
>>> host plus fragment would not be in conflict.
>>>
>>> now if you're attaching the fragment to an already resolved host then I
>>> believe the
>>> resolver would look at the existing wires, not the original range -
>>> so if
>>> the host was
>>> already wired to 2.1.0 then the fragment wouldn't be able to attach
>>> dynamically
>>>
>>> but then this is still correct (afaik) in that you can't dynamically
>>> attach
>>> a fragment
>>> that conflicts with the resolved host (btw, do we support dynamic
>>> attachment?)
>>
>> No, we don't.
>>
>>>> We may have following condition to enable fragment:
>>>> 1. exact version match or
>>>> 2. host version range inside all fragments version or
>>>> 3. all fragments and host share intersection + dynamic verify the
>>>> actual imported version is inside intersection
>>>> (p.s. I am not sure "dynamic verify the actual imported version is
>>>> inside intersection" is viable or not. If not, we could do at least
>>>> step 2 which will help both Andreas's and FELIX-1919 case )
>>>>
>>> these still fall under 'intersection' imho (ie. the intersection should
>>> apply to the
>>> host and fragment) but let's see what Richard's algorithm actually
>>> looks
>>> like :)
>>
>> The intersection approach will create a new version range each time a
>> fragment is added and the next fragment will be compared against that
>> range in bundle ID order. I don't think this will allow for any valid
>> cases since we are always making the allowed version range more narror.
>
> Should say "any invalid cases"..."more narrow"...
>
> -> richard
>
>>
>> -> richard
>>
>>>
>>>> -Guo
>>>>
Re: Less restrictive conflict resolution for fragment imports
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 12/17/09 9:42, Richard S. Hall wrote:
> On 12/17/09 8:27, Stuart McCulloch wrote:
>> 2009/12/17 Guo Du<mr...@gmail.com>
>>
>>> On Wed, Dec 16, 2009 at 5:37 PM, Stuart McCulloch<mc...@gmail.com>
>>> wrote:
>>>> So +1 to trying the intersection approach.
>>> Intersection ONLY is not safe for the case:
>>>> Host version [2.0.0,3.0.0)
>>>> [2.5.0,2.9.0)
>>>> Fails, when host is importing 2.1.0 this would cause fragment to fail.
>> depends when the intersection was made - if it was done before the host
>> resolved
>> then the host's import range would shrink to the intersection:
>> [2.5.0,2.9.0)
>> and the
>> host plus fragment would not be in conflict.
>>
>> now if you're attaching the fragment to an already resolved host then I
>> believe the
>> resolver would look at the existing wires, not the original range -
>> so if
>> the host was
>> already wired to 2.1.0 then the fragment wouldn't be able to attach
>> dynamically
>>
>> but then this is still correct (afaik) in that you can't dynamically
>> attach
>> a fragment
>> that conflicts with the resolved host (btw, do we support dynamic
>> attachment?)
>
> No, we don't.
>
>>> We may have following condition to enable fragment:
>>> 1. exact version match or
>>> 2. host version range inside all fragments version or
>>> 3. all fragments and host share intersection + dynamic verify the
>>> actual imported version is inside intersection
>>> (p.s. I am not sure "dynamic verify the actual imported version is
>>> inside intersection" is viable or not. If not, we could do at least
>>> step 2 which will help both Andreas's and FELIX-1919 case )
>>>
>> these still fall under 'intersection' imho (ie. the intersection should
>> apply to the
>> host and fragment) but let's see what Richard's algorithm actually looks
>> like :)
>
> The intersection approach will create a new version range each time a
> fragment is added and the next fragment will be compared against that
> range in bundle ID order. I don't think this will allow for any valid
> cases since we are always making the allowed version range more narror.
Should say "any invalid cases"..."more narrow"...
-> richard
>
> -> richard
>
>>
>>> -Guo
>>>
Re: Less restrictive conflict resolution for fragment imports
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 12/17/09 8:27, Stuart McCulloch wrote:
> 2009/12/17 Guo Du<mr...@gmail.com>
>
>
>> On Wed, Dec 16, 2009 at 5:37 PM, Stuart McCulloch<mc...@gmail.com>
>> wrote:
>>
>>> So +1 to trying the intersection approach.
>>>
>> Intersection ONLY is not safe for the case:
>>
>>> Host version [2.0.0,3.0.0)
>>> [2.5.0,2.9.0)
>>> Fails, when host is importing 2.1.0 this would cause fragment to fail.
>>>
>>
> depends when the intersection was made - if it was done before the host
> resolved
> then the host's import range would shrink to the intersection: [2.5.0,2.9.0)
> and the
> host plus fragment would not be in conflict.
>
> now if you're attaching the fragment to an already resolved host then I
> believe the
> resolver would look at the existing wires, not the original range - so if
> the host was
> already wired to 2.1.0 then the fragment wouldn't be able to attach
> dynamically
>
> but then this is still correct (afaik) in that you can't dynamically attach
> a fragment
> that conflicts with the resolved host (btw, do we support dynamic
> attachment?)
>
No, we don't.
>> We may have following condition to enable fragment:
>> 1. exact version match or
>> 2. host version range inside all fragments version or
>> 3. all fragments and host share intersection + dynamic verify the
>> actual imported version is inside intersection
>> (p.s. I am not sure "dynamic verify the actual imported version is
>> inside intersection" is viable or not. If not, we could do at least
>> step 2 which will help both Andreas's and FELIX-1919 case )
>>
>>
> these still fall under 'intersection' imho (ie. the intersection should
> apply to the
> host and fragment) but let's see what Richard's algorithm actually looks
> like :)
>
The intersection approach will create a new version range each time a
fragment is added and the next fragment will be compared against that
range in bundle ID order. I don't think this will allow for any valid
cases since we are always making the allowed version range more narror.
-> richard
>
>
>> -Guo
>>
>>
>
Re: Less restrictive conflict resolution for fragment imports
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/12/17 Guo Du <mr...@gmail.com>
> On Wed, Dec 16, 2009 at 5:37 PM, Stuart McCulloch <mc...@gmail.com>
> wrote:
> > So +1 to trying the intersection approach.
>
> Intersection ONLY is not safe for the case:
> > Host version [2.0.0,3.0.0)
> > [2.5.0,2.9.0)
> > Fails, when host is importing 2.1.0 this would cause fragment to fail.
>
depends when the intersection was made - if it was done before the host
resolved
then the host's import range would shrink to the intersection: [2.5.0,2.9.0)
and the
host plus fragment would not be in conflict.
now if you're attaching the fragment to an already resolved host then I
believe the
resolver would look at the existing wires, not the original range - so if
the host was
already wired to 2.1.0 then the fragment wouldn't be able to attach
dynamically
but then this is still correct (afaik) in that you can't dynamically attach
a fragment
that conflicts with the resolved host (btw, do we support dynamic
attachment?)
> We may have following condition to enable fragment:
> 1. exact version match or
> 2. host version range inside all fragments version or
> 3. all fragments and host share intersection + dynamic verify the
> actual imported version is inside intersection
> (p.s. I am not sure "dynamic verify the actual imported version is
> inside intersection" is viable or not. If not, we could do at least
> step 2 which will help both Andreas's and FELIX-1919 case )
>
these still fall under 'intersection' imho (ie. the intersection should
apply to the
host and fragment) but let's see what Richard's algorithm actually looks
like :)
> -Guo
>
--
Cheers, Stuart
Re: Less restrictive conflict resolution for fragment imports
Posted by Guo Du <mr...@gmail.com>.
On Wed, Dec 16, 2009 at 5:37 PM, Stuart McCulloch <mc...@gmail.com> wrote:
> So +1 to trying the intersection approach.
Intersection ONLY is not safe for the case:
> Host version [2.0.0,3.0.0)
> [2.5.0,2.9.0)
> Fails, when host is importing 2.1.0 this would cause fragment to fail.
We may have following condition to enable fragment:
1. exact version match or
2. host version range inside all fragments version or
3. all fragments and host share intersection + dynamic verify the
actual imported version is inside intersection
(p.s. I am not sure "dynamic verify the actual imported version is
inside intersection" is viable or not. If not, we could do at least
step 2 which will help both Andreas's and FELIX-1919 case )
-Guo
Re: Less restrictive conflict resolution for fragment imports
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/12/17 Richard S. Hall <he...@ungoverned.org>
> On 12/16/09 12:15, Andreas.Schlosser@sybase.com wrote:
>
>> Trying to summarize what I was trying to say, I believe both ways are
>> valid and have there own advantages and at the end it is more a matter of
>> taste (or doing it the same way as Equinox to ensure sort of consistency
>> across frameworks).
>>
>
> Given the differences in our resolver impls, I am not sure it will be
> possible for us to do it the same way, but my guess is that the intersection
> approach would work in most cases where people would expect it.
>
IMHO it's generally better to try and interpret the spec (like in this
discussion), rather than default to whatever Equinox does :)
That way we can identify any vagueness / ambiguities in the spec and get the
chance to come up with some innovative ideas,
such as Karl's security work. Also there have been some rare situations
where the spec and Equinox have differed in the past.
So +1 to trying the intersection approach.
> -> richard
>
>
> Statically using the host bundle versions leads to a more predictable
>> behaviour at build time, whereas dynamically adjusting to fragment imports
>> leads to better runtime resolution.
>>
>> We could very well go for the dynamic solution, but encourage the "good
>> way of doing fragments" by not restricting the host import versions...
>>
>> Thanks
>> Andreas
>>
>> "Richard S. Hall"<he...@ungoverned.org> wrote on 12/16/2009 09:00:24 AM:
>>
>>
>>
>>> p.s. I should point out, I am not against your approach. It is a little
>>> more restrictive than what I am proposing, but more lenient than
>>> currently implemented. Rather than requiring floor and ceiling of the
>>> fragment to be == to the host range, like the current approach, you
>>> require the floor and ceiling of the fragment to be<=/>= the host
>>>
>>>
>> range.
>>
>>
>>> On 12/16/09 11:48, Andreas.Schlosser@sybase.com wrote:
>>>
>>>
>>>> Richard,
>>>>
>>>> this could also work, but will add more complexity to it. You may run
>>>>
>>>>
>>> into
>>
>>
>>> situations were you need to randomly abandon one fragment:
>>>>
>>>> Host imports version [1.0.0,2.0.0), fragment 1 imports [1.0.0,1.5.0),
>>>> fragment 2 imports [1.5.0,2.0.0)
>>>>
>>>> In my approach, both fragments would be exluded, in your approach you
>>>>
>>>>
>>> have
>>
>>
>>> to find a tie breaker to decide on which fragment to include.
>>>>
>>>> With my approach, statically determining the valid version range by
>>>> looking at the host bundle, you'd keep the control over valid versions
>>>> with the host bundle and everybody using it can be sure that the host
>>>>
>>>>
>>> and
>>
>>
>>> all possibly existing fragments will run when obeying the host version
>>>> range (so, when using a consistent set of bundles you can be sure that
>>>>
>>>>
>>> you
>>
>>
>>> can add any fragment you want without updating other bundles). When
>>>> dynamically determining the version range by looking at fragments as
>>>>
>>>>
>>> well,
>>
>>
>>> you'd take away this guarantee. It may happen that a consistent set of
>>>> bundles gets inconsistent out of a sudden because of a fragment with
>>>>
>>>>
>>> too
>>
>>
>>> restrictive import versions (meaning the fragment does not work).
>>>>
>>>> The dynamic approach obviously has the advantage to be more flexible,
>>>>
>>>>
>>> but
>>
>>
>>> I think it should rather be the responsibility of a fragment developer
>>>>
>>>>
>>> to
>>
>>
>>> adhere to the version ranges of the host bundle than the
>>>>
>>>>
>>> responsibility of
>>
>>
>>> the user of a host bundle to comply to (more restrictive) version
>>>>
>>>>
>>> ranges
>>
>>
>>> in fragments he'd like to use.
>>>>
>>>> Maybe it would be interesting to look into how Equinox is doing it,
>>>> unfortunately I don't know. Can anybody help?
>>>>
>>>> Thanks
>>>> Andreas
>>>>
>>>>
>>>> "Richard S. Hall"<he...@ungoverned.org> wrote on 12/16/2009 08:30:10
>>>>
>>>>
>>> AM:
>>
>>
>>>
>>>>
>>>>
>>>>> What I was planning on doing is taking the intersection, which would
>>>>>
>>>>>
>>>> be
>>
>>
>>> the highest floor and the lowest ceiling of each overlapping version
>>>>> range...and of course, if there is no intersection, then they are in
>>>>> conflict and the fragment would be thrown out.
>>>>>
>>>>> -> richard
>>>>>
>>>>> On 12/16/09 11:13, Andreas.Schlosser@sybase.com wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Guo,
>>>>>>
>>>>>> I think your algorithm is not 100% correct. The host version
>>>>>>
>>>>>>
>>>>>>
>>>>> boundaries
>>>>
>>>>
>>>>
>>>>> must lie within the fragment version boundaries. So, looking at your
>>>>>> example:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Host version [2.0.0,3.0.0)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>> Fail fragment versions [1.0.0], [1.0.0,2.0.0), [3.0.0]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Fails, since version lies completely outside host version boundaries
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Pass fragment versions
>>>>>>> [1.0.0,5.0.0),
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Passes, since host version lies within these boundaries
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> [2.5.0,2.9.0)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Fails, since host version lies outside boundaries. E.g., when host
>>>>>>
>>>>>>
>>>>> is
>>
>>
>>> importing 2.1.0 this would cause fragment to fail.
>>>>>>
>>>>>> Thanks,
>>>>>> Andreas
>>>>>>
>>>>>>
>>>>>> Guo Du<mr...@gmail.com> wrote on 12/16/2009 02:25:50 AM:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Wed, Dec 16, 2009 at 12:54 AM,<An...@sybase.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> wrote:
>>>>
>>>>
>>>>
>>>>>
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I found that Felix is validating the compatibility of host vs.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> fragment
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> imports by ensuring that in case host and fragment are importing
>>>>>>>>
>>>>>>>>
>>>>>>> the
>>
>>
>>>
>>>>>>>>
>>>>>>>>
>>>>>>> same
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> package, they should use the exactly same version (range). I
>>>>>>>>
>>>>>>>>
>>>>>>> believe
>>
>>
>>>
>>>>>>>>
>>>>>>>>
>>>>>>> that
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> this is a little too restrictive and Felix should also allow the
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> host
>>>>
>>>>
>>>>
>>>>> bundle to be more restrictive on the version range than the
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> fragment.
>>>>
>>>>
>>>>
>>>>>
>>>>>>>>
>>>>>>> This
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> way, it is still guaranteed that the fragment will run with using
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> the
>>>>
>>>>
>>>>
>>>>> version range from the host bundle (which is a subset of the
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> fragment
>>>>
>>>>
>>>>
>>>>> version range in this case).
>>>>>>>>
>>>>>>>> I just ran into this problem when trying to use the Hibernate +
>>>>>>>> Annotations bundles packaged by SpringSource. Hibernate
>>>>>>>>
>>>>>>>>
>>>>>>> Annotations
>>
>>
>>>
>>>>>>>>
>>>>>>> is
>>>>
>>>>
>>>>
>>>>>
>>>>>>>>
>>>>>>> a
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> fragment bundle, hosted by the Hibernate bundle. Hibernate imports
>>>>>>>> org.dom4j;version="[1.6.1, 1.7.0)" whereas the fragment imports
>>>>>>>> org.dom4j;version="[1.6.1, 2.0.0)" and the current implementation
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> does
>>>>
>>>>
>>>>
>>>>>
>>>>>>>>
>>>>>>> not
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> allow this fragment to be linked to its host.
>>>>>>>>
>>>>>>>> What do you think?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> I have this problem with spring-osgi-extender as well. For
>>>>>>>
>>>>>>>
>>>>>> fragment,
>>
>>
>>> we may enable the fragment when there are common set between host
>>>>>>> version and fragment version.
>>>>>>>
>>>>>>> Host version [2.0.0,3.0.0)
>>>>>>> Fail fragment versions [1.0.0], [1.0.0,2.0.0), [3.0.0]
>>>>>>> Pass fragment versions [1.0.0,5.0.0), [2.5.0,2.9.0)
>>>>>>>
>>>>>>> Any drawback to this approach?
>>>>>>>
>>>>>>> -Guo
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
--
Cheers, Stuart
Re: Less restrictive conflict resolution for fragment imports
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 12/16/09 12:15, Andreas.Schlosser@sybase.com wrote:
> Trying to summarize what I was trying to say, I believe both ways are
> valid and have there own advantages and at the end it is more a matter of
> taste (or doing it the same way as Equinox to ensure sort of consistency
> across frameworks).
>
Given the differences in our resolver impls, I am not sure it will be
possible for us to do it the same way, but my guess is that the
intersection approach would work in most cases where people would expect it.
-> richard
> Statically using the host bundle versions leads to a more predictable
> behaviour at build time, whereas dynamically adjusting to fragment imports
> leads to better runtime resolution.
>
> We could very well go for the dynamic solution, but encourage the "good
> way of doing fragments" by not restricting the host import versions...
>
> Thanks
> Andreas
>
> "Richard S. Hall"<he...@ungoverned.org> wrote on 12/16/2009 09:00:24 AM:
>
>
>> p.s. I should point out, I am not against your approach. It is a little
>> more restrictive than what I am proposing, but more lenient than
>> currently implemented. Rather than requiring floor and ceiling of the
>> fragment to be == to the host range, like the current approach, you
>> require the floor and ceiling of the fragment to be<=/>= the host
>>
> range.
>
>> On 12/16/09 11:48, Andreas.Schlosser@sybase.com wrote:
>>
>>> Richard,
>>>
>>> this could also work, but will add more complexity to it. You may run
>>>
> into
>
>>> situations were you need to randomly abandon one fragment:
>>>
>>> Host imports version [1.0.0,2.0.0), fragment 1 imports [1.0.0,1.5.0),
>>> fragment 2 imports [1.5.0,2.0.0)
>>>
>>> In my approach, both fragments would be exluded, in your approach you
>>>
> have
>
>>> to find a tie breaker to decide on which fragment to include.
>>>
>>> With my approach, statically determining the valid version range by
>>> looking at the host bundle, you'd keep the control over valid versions
>>> with the host bundle and everybody using it can be sure that the host
>>>
> and
>
>>> all possibly existing fragments will run when obeying the host version
>>> range (so, when using a consistent set of bundles you can be sure that
>>>
> you
>
>>> can add any fragment you want without updating other bundles). When
>>> dynamically determining the version range by looking at fragments as
>>>
> well,
>
>>> you'd take away this guarantee. It may happen that a consistent set of
>>> bundles gets inconsistent out of a sudden because of a fragment with
>>>
> too
>
>>> restrictive import versions (meaning the fragment does not work).
>>>
>>> The dynamic approach obviously has the advantage to be more flexible,
>>>
> but
>
>>> I think it should rather be the responsibility of a fragment developer
>>>
> to
>
>>> adhere to the version ranges of the host bundle than the
>>>
> responsibility of
>
>>> the user of a host bundle to comply to (more restrictive) version
>>>
> ranges
>
>>> in fragments he'd like to use.
>>>
>>> Maybe it would be interesting to look into how Equinox is doing it,
>>> unfortunately I don't know. Can anybody help?
>>>
>>> Thanks
>>> Andreas
>>>
>>>
>>> "Richard S. Hall"<he...@ungoverned.org> wrote on 12/16/2009 08:30:10
>>>
> AM:
>
>>>
>>>
>>>> What I was planning on doing is taking the intersection, which would
>>>>
> be
>
>>>> the highest floor and the lowest ceiling of each overlapping version
>>>> range...and of course, if there is no intersection, then they are in
>>>> conflict and the fragment would be thrown out.
>>>>
>>>> -> richard
>>>>
>>>> On 12/16/09 11:13, Andreas.Schlosser@sybase.com wrote:
>>>>
>>>>
>>>>> Guo,
>>>>>
>>>>> I think your algorithm is not 100% correct. The host version
>>>>>
>>>>>
>>> boundaries
>>>
>>>
>>>>> must lie within the fragment version boundaries. So, looking at your
>>>>> example:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Host version [2.0.0,3.0.0)
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>> Fail fragment versions [1.0.0], [1.0.0,2.0.0), [3.0.0]
>>>>>>
>>>>>>
>>>>>>
>>>>> Fails, since version lies completely outside host version boundaries
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Pass fragment versions
>>>>>> [1.0.0,5.0.0),
>>>>>>
>>>>>>
>>>>>>
>>>>> Passes, since host version lies within these boundaries
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> [2.5.0,2.9.0)
>>>>>>
>>>>>>
>>>>>>
>>>>> Fails, since host version lies outside boundaries. E.g., when host
>>>>>
> is
>
>>>>> importing 2.1.0 this would cause fragment to fail.
>>>>>
>>>>> Thanks,
>>>>> Andreas
>>>>>
>>>>>
>>>>> Guo Du<mr...@gmail.com> wrote on 12/16/2009 02:25:50 AM:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Wed, Dec 16, 2009 at 12:54 AM,<An...@sybase.com>
>>>>>>
>>>>>>
>>> wrote:
>>>
>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I found that Felix is validating the compatibility of host vs.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> fragment
>>>>>
>>>>>
>>>>>
>>>>>>> imports by ensuring that in case host and fragment are importing
>>>>>>>
> the
>
>>>>>>>
>>>>>>>
>>>>> same
>>>>>
>>>>>
>>>>>
>>>>>>> package, they should use the exactly same version (range). I
>>>>>>>
> believe
>
>>>>>>>
>>>>>>>
>>>>> that
>>>>>
>>>>>
>>>>>
>>>>>>> this is a little too restrictive and Felix should also allow the
>>>>>>>
>>>>>>>
>>> host
>>>
>>>
>>>>>>> bundle to be more restrictive on the version range than the
>>>>>>>
>>>>>>>
>>> fragment.
>>>
>>>
>>>>>>>
>>>>> This
>>>>>
>>>>>
>>>>>
>>>>>>> way, it is still guaranteed that the fragment will run with using
>>>>>>>
>>>>>>>
>>> the
>>>
>>>
>>>>>>> version range from the host bundle (which is a subset of the
>>>>>>>
>>>>>>>
>>> fragment
>>>
>>>
>>>>>>> version range in this case).
>>>>>>>
>>>>>>> I just ran into this problem when trying to use the Hibernate +
>>>>>>> Annotations bundles packaged by SpringSource. Hibernate
>>>>>>>
> Annotations
>
>>>>>>>
>>> is
>>>
>>>
>>>>>>>
>>>>> a
>>>>>
>>>>>
>>>>>
>>>>>>> fragment bundle, hosted by the Hibernate bundle. Hibernate imports
>>>>>>> org.dom4j;version="[1.6.1, 1.7.0)" whereas the fragment imports
>>>>>>> org.dom4j;version="[1.6.1, 2.0.0)" and the current implementation
>>>>>>>
>>>>>>>
>>> does
>>>
>>>
>>>>>>>
>>>>> not
>>>>>
>>>>>
>>>>>
>>>>>>> allow this fragment to be linked to its host.
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> +1
>>>>>>
>>>>>> I have this problem with spring-osgi-extender as well. For
>>>>>>
> fragment,
>
>>>>>> we may enable the fragment when there are common set between host
>>>>>> version and fragment version.
>>>>>>
>>>>>> Host version [2.0.0,3.0.0)
>>>>>> Fail fragment versions [1.0.0], [1.0.0,2.0.0), [3.0.0]
>>>>>> Pass fragment versions [1.0.0,5.0.0), [2.5.0,2.9.0)
>>>>>>
>>>>>> Any drawback to this approach?
>>>>>>
>>>>>> -Guo
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Less restrictive conflict resolution for fragment imports
Posted by An...@sybase.com.
Trying to summarize what I was trying to say, I believe both ways are
valid and have there own advantages and at the end it is more a matter of
taste (or doing it the same way as Equinox to ensure sort of consistency
across frameworks).
Statically using the host bundle versions leads to a more predictable
behaviour at build time, whereas dynamically adjusting to fragment imports
leads to better runtime resolution.
We could very well go for the dynamic solution, but encourage the "good
way of doing fragments" by not restricting the host import versions...
Thanks
Andreas
"Richard S. Hall" <he...@ungoverned.org> wrote on 12/16/2009 09:00:24 AM:
> p.s. I should point out, I am not against your approach. It is a little
> more restrictive than what I am proposing, but more lenient than
> currently implemented. Rather than requiring floor and ceiling of the
> fragment to be == to the host range, like the current approach, you
> require the floor and ceiling of the fragment to be <=/>= the host
range.
>
> On 12/16/09 11:48, Andreas.Schlosser@sybase.com wrote:
> > Richard,
> >
> > this could also work, but will add more complexity to it. You may run
into
> > situations were you need to randomly abandon one fragment:
> >
> > Host imports version [1.0.0,2.0.0), fragment 1 imports [1.0.0,1.5.0),
> > fragment 2 imports [1.5.0,2.0.0)
> >
> > In my approach, both fragments would be exluded, in your approach you
have
> > to find a tie breaker to decide on which fragment to include.
> >
> > With my approach, statically determining the valid version range by
> > looking at the host bundle, you'd keep the control over valid versions
> > with the host bundle and everybody using it can be sure that the host
and
> > all possibly existing fragments will run when obeying the host version
> > range (so, when using a consistent set of bundles you can be sure that
you
> > can add any fragment you want without updating other bundles). When
> > dynamically determining the version range by looking at fragments as
well,
> > you'd take away this guarantee. It may happen that a consistent set of
> > bundles gets inconsistent out of a sudden because of a fragment with
too
> > restrictive import versions (meaning the fragment does not work).
> >
> > The dynamic approach obviously has the advantage to be more flexible,
but
> > I think it should rather be the responsibility of a fragment developer
to
> > adhere to the version ranges of the host bundle than the
responsibility of
> > the user of a host bundle to comply to (more restrictive) version
ranges
> > in fragments he'd like to use.
> >
> > Maybe it would be interesting to look into how Equinox is doing it,
> > unfortunately I don't know. Can anybody help?
> >
> > Thanks
> > Andreas
> >
> >
> > "Richard S. Hall"<he...@ungoverned.org> wrote on 12/16/2009 08:30:10
AM:
> >
> >
> >> What I was planning on doing is taking the intersection, which would
be
> >> the highest floor and the lowest ceiling of each overlapping version
> >> range...and of course, if there is no intersection, then they are in
> >> conflict and the fragment would be thrown out.
> >>
> >> -> richard
> >>
> >> On 12/16/09 11:13, Andreas.Schlosser@sybase.com wrote:
> >>
> >>> Guo,
> >>>
> >>> I think your algorithm is not 100% correct. The host version
> >>>
> > boundaries
> >
> >>> must lie within the fragment version boundaries. So, looking at your
> >>> example:
> >>>
> >>>
> >>>
> >>>> Host version [2.0.0,3.0.0)
> >>>>
> >>>>
> >>>
> >>>> Fail fragment versions [1.0.0], [1.0.0,2.0.0), [3.0.0]
> >>>>
> >>>>
> >>> Fails, since version lies completely outside host version boundaries
> >>>
> >>>
> >>>
> >>>> Pass fragment versions
> >>>> [1.0.0,5.0.0),
> >>>>
> >>>>
> >>> Passes, since host version lies within these boundaries
> >>>
> >>>
> >>>
> >>>> [2.5.0,2.9.0)
> >>>>
> >>>>
> >>> Fails, since host version lies outside boundaries. E.g., when host
is
> >>> importing 2.1.0 this would cause fragment to fail.
> >>>
> >>> Thanks,
> >>> Andreas
> >>>
> >>>
> >>> Guo Du<mr...@gmail.com> wrote on 12/16/2009 02:25:50 AM:
> >>>
> >>>
> >>>
> >>>> On Wed, Dec 16, 2009 at 12:54 AM,<An...@sybase.com>
> >>>>
> > wrote:
> >
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I found that Felix is validating the compatibility of host vs.
> >>>>>
> >>>>>
> >>> fragment
> >>>
> >>>
> >>>>> imports by ensuring that in case host and fragment are importing
the
> >>>>>
> >>>>>
> >>> same
> >>>
> >>>
> >>>>> package, they should use the exactly same version (range). I
believe
> >>>>>
> >>>>>
> >>> that
> >>>
> >>>
> >>>>> this is a little too restrictive and Felix should also allow the
> >>>>>
> > host
> >
> >>>>> bundle to be more restrictive on the version range than the
> >>>>>
> > fragment.
> >
> >>>>>
> >>> This
> >>>
> >>>
> >>>>> way, it is still guaranteed that the fragment will run with using
> >>>>>
> > the
> >
> >>>>> version range from the host bundle (which is a subset of the
> >>>>>
> > fragment
> >
> >>>>> version range in this case).
> >>>>>
> >>>>> I just ran into this problem when trying to use the Hibernate +
> >>>>> Annotations bundles packaged by SpringSource. Hibernate
Annotations
> >>>>>
> > is
> >
> >>>>>
> >>> a
> >>>
> >>>
> >>>>> fragment bundle, hosted by the Hibernate bundle. Hibernate imports
> >>>>> org.dom4j;version="[1.6.1, 1.7.0)" whereas the fragment imports
> >>>>> org.dom4j;version="[1.6.1, 2.0.0)" and the current implementation
> >>>>>
> > does
> >
> >>>>>
> >>> not
> >>>
> >>>
> >>>>> allow this fragment to be linked to its host.
> >>>>>
> >>>>> What do you think?
> >>>>>
> >>>>>
> >>>> +1
> >>>>
> >>>> I have this problem with spring-osgi-extender as well. For
fragment,
> >>>> we may enable the fragment when there are common set between host
> >>>> version and fragment version.
> >>>>
> >>>> Host version [2.0.0,3.0.0)
> >>>> Fail fragment versions [1.0.0], [1.0.0,2.0.0), [3.0.0]
> >>>> Pass fragment versions [1.0.0,5.0.0), [2.5.0,2.9.0)
> >>>>
> >>>> Any drawback to this approach?
> >>>>
> >>>> -Guo
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
>
Re: Less restrictive conflict resolution for fragment imports
Posted by "Richard S. Hall" <he...@ungoverned.org>.
p.s. I should point out, I am not against your approach. It is a little
more restrictive than what I am proposing, but more lenient than
currently implemented. Rather than requiring floor and ceiling of the
fragment to be == to the host range, like the current approach, you
require the floor and ceiling of the fragment to be <=/>= the host range.
On 12/16/09 11:48, Andreas.Schlosser@sybase.com wrote:
> Richard,
>
> this could also work, but will add more complexity to it. You may run into
> situations were you need to randomly abandon one fragment:
>
> Host imports version [1.0.0,2.0.0), fragment 1 imports [1.0.0,1.5.0),
> fragment 2 imports [1.5.0,2.0.0)
>
> In my approach, both fragments would be exluded, in your approach you have
> to find a tie breaker to decide on which fragment to include.
>
> With my approach, statically determining the valid version range by
> looking at the host bundle, you'd keep the control over valid versions
> with the host bundle and everybody using it can be sure that the host and
> all possibly existing fragments will run when obeying the host version
> range (so, when using a consistent set of bundles you can be sure that you
> can add any fragment you want without updating other bundles). When
> dynamically determining the version range by looking at fragments as well,
> you'd take away this guarantee. It may happen that a consistent set of
> bundles gets inconsistent out of a sudden because of a fragment with too
> restrictive import versions (meaning the fragment does not work).
>
> The dynamic approach obviously has the advantage to be more flexible, but
> I think it should rather be the responsibility of a fragment developer to
> adhere to the version ranges of the host bundle than the responsibility of
> the user of a host bundle to comply to (more restrictive) version ranges
> in fragments he'd like to use.
>
> Maybe it would be interesting to look into how Equinox is doing it,
> unfortunately I don't know. Can anybody help?
>
> Thanks
> Andreas
>
>
> "Richard S. Hall"<he...@ungoverned.org> wrote on 12/16/2009 08:30:10 AM:
>
>
>> What I was planning on doing is taking the intersection, which would be
>> the highest floor and the lowest ceiling of each overlapping version
>> range...and of course, if there is no intersection, then they are in
>> conflict and the fragment would be thrown out.
>>
>> -> richard
>>
>> On 12/16/09 11:13, Andreas.Schlosser@sybase.com wrote:
>>
>>> Guo,
>>>
>>> I think your algorithm is not 100% correct. The host version
>>>
> boundaries
>
>>> must lie within the fragment version boundaries. So, looking at your
>>> example:
>>>
>>>
>>>
>>>> Host version [2.0.0,3.0.0)
>>>>
>>>>
>>>
>>>> Fail fragment versions [1.0.0], [1.0.0,2.0.0), [3.0.0]
>>>>
>>>>
>>> Fails, since version lies completely outside host version boundaries
>>>
>>>
>>>
>>>> Pass fragment versions
>>>> [1.0.0,5.0.0),
>>>>
>>>>
>>> Passes, since host version lies within these boundaries
>>>
>>>
>>>
>>>> [2.5.0,2.9.0)
>>>>
>>>>
>>> Fails, since host version lies outside boundaries. E.g., when host is
>>> importing 2.1.0 this would cause fragment to fail.
>>>
>>> Thanks,
>>> Andreas
>>>
>>>
>>> Guo Du<mr...@gmail.com> wrote on 12/16/2009 02:25:50 AM:
>>>
>>>
>>>
>>>> On Wed, Dec 16, 2009 at 12:54 AM,<An...@sybase.com>
>>>>
> wrote:
>
>>>>
>>>>> Hi,
>>>>>
>>>>> I found that Felix is validating the compatibility of host vs.
>>>>>
>>>>>
>>> fragment
>>>
>>>
>>>>> imports by ensuring that in case host and fragment are importing the
>>>>>
>>>>>
>>> same
>>>
>>>
>>>>> package, they should use the exactly same version (range). I believe
>>>>>
>>>>>
>>> that
>>>
>>>
>>>>> this is a little too restrictive and Felix should also allow the
>>>>>
> host
>
>>>>> bundle to be more restrictive on the version range than the
>>>>>
> fragment.
>
>>>>>
>>> This
>>>
>>>
>>>>> way, it is still guaranteed that the fragment will run with using
>>>>>
> the
>
>>>>> version range from the host bundle (which is a subset of the
>>>>>
> fragment
>
>>>>> version range in this case).
>>>>>
>>>>> I just ran into this problem when trying to use the Hibernate +
>>>>> Annotations bundles packaged by SpringSource. Hibernate Annotations
>>>>>
> is
>
>>>>>
>>> a
>>>
>>>
>>>>> fragment bundle, hosted by the Hibernate bundle. Hibernate imports
>>>>> org.dom4j;version="[1.6.1, 1.7.0)" whereas the fragment imports
>>>>> org.dom4j;version="[1.6.1, 2.0.0)" and the current implementation
>>>>>
> does
>
>>>>>
>>> not
>>>
>>>
>>>>> allow this fragment to be linked to its host.
>>>>>
>>>>> What do you think?
>>>>>
>>>>>
>>>> +1
>>>>
>>>> I have this problem with spring-osgi-extender as well. For fragment,
>>>> we may enable the fragment when there are common set between host
>>>> version and fragment version.
>>>>
>>>> Host version [2.0.0,3.0.0)
>>>> Fail fragment versions [1.0.0], [1.0.0,2.0.0), [3.0.0]
>>>> Pass fragment versions [1.0.0,5.0.0), [2.5.0,2.9.0)
>>>>
>>>> Any drawback to this approach?
>>>>
>>>> -Guo
>>>>
>>>>
>>>>
>>>
>>
>
Re: Less restrictive conflict resolution for fragment imports
Posted by An...@sybase.com.
Richard,
this could also work, but will add more complexity to it. You may run into
situations were you need to randomly abandon one fragment:
Host imports version [1.0.0,2.0.0), fragment 1 imports [1.0.0,1.5.0),
fragment 2 imports [1.5.0,2.0.0)
In my approach, both fragments would be exluded, in your approach you have
to find a tie breaker to decide on which fragment to include.
With my approach, statically determining the valid version range by
looking at the host bundle, you'd keep the control over valid versions
with the host bundle and everybody using it can be sure that the host and
all possibly existing fragments will run when obeying the host version
range (so, when using a consistent set of bundles you can be sure that you
can add any fragment you want without updating other bundles). When
dynamically determining the version range by looking at fragments as well,
you'd take away this guarantee. It may happen that a consistent set of
bundles gets inconsistent out of a sudden because of a fragment with too
restrictive import versions (meaning the fragment does not work).
The dynamic approach obviously has the advantage to be more flexible, but
I think it should rather be the responsibility of a fragment developer to
adhere to the version ranges of the host bundle than the responsibility of
the user of a host bundle to comply to (more restrictive) version ranges
in fragments he'd like to use.
Maybe it would be interesting to look into how Equinox is doing it,
unfortunately I don't know. Can anybody help?
Thanks
Andreas
"Richard S. Hall" <he...@ungoverned.org> wrote on 12/16/2009 08:30:10 AM:
> What I was planning on doing is taking the intersection, which would be
> the highest floor and the lowest ceiling of each overlapping version
> range...and of course, if there is no intersection, then they are in
> conflict and the fragment would be thrown out.
>
> -> richard
>
> On 12/16/09 11:13, Andreas.Schlosser@sybase.com wrote:
> > Guo,
> >
> > I think your algorithm is not 100% correct. The host version
boundaries
> > must lie within the fragment version boundaries. So, looking at your
> > example:
> >
> >
> >> Host version [2.0.0,3.0.0)
> >>
> >
> >> Fail fragment versions [1.0.0], [1.0.0,2.0.0), [3.0.0]
> >>
> > Fails, since version lies completely outside host version boundaries
> >
> >
> >> Pass fragment versions
> >> [1.0.0,5.0.0),
> >>
> > Passes, since host version lies within these boundaries
> >
> >
> >> [2.5.0,2.9.0)
> >>
> > Fails, since host version lies outside boundaries. E.g., when host is
> > importing 2.1.0 this would cause fragment to fail.
> >
> > Thanks,
> > Andreas
> >
> >
> > Guo Du<mr...@gmail.com> wrote on 12/16/2009 02:25:50 AM:
> >
> >
> >> On Wed, Dec 16, 2009 at 12:54 AM,<An...@sybase.com>
wrote:
> >>
> >>> Hi,
> >>>
> >>> I found that Felix is validating the compatibility of host vs.
> >>>
> > fragment
> >
> >>> imports by ensuring that in case host and fragment are importing the
> >>>
> > same
> >
> >>> package, they should use the exactly same version (range). I believe
> >>>
> > that
> >
> >>> this is a little too restrictive and Felix should also allow the
host
> >>> bundle to be more restrictive on the version range than the
fragment.
> >>>
> > This
> >
> >>> way, it is still guaranteed that the fragment will run with using
the
> >>> version range from the host bundle (which is a subset of the
fragment
> >>> version range in this case).
> >>>
> >>> I just ran into this problem when trying to use the Hibernate +
> >>> Annotations bundles packaged by SpringSource. Hibernate Annotations
is
> >>>
> > a
> >
> >>> fragment bundle, hosted by the Hibernate bundle. Hibernate imports
> >>> org.dom4j;version="[1.6.1, 1.7.0)" whereas the fragment imports
> >>> org.dom4j;version="[1.6.1, 2.0.0)" and the current implementation
does
> >>>
> > not
> >
> >>> allow this fragment to be linked to its host.
> >>>
> >>> What do you think?
> >>>
> >> +1
> >>
> >> I have this problem with spring-osgi-extender as well. For fragment,
> >> we may enable the fragment when there are common set between host
> >> version and fragment version.
> >>
> >> Host version [2.0.0,3.0.0)
> >> Fail fragment versions [1.0.0], [1.0.0,2.0.0), [3.0.0]
> >> Pass fragment versions [1.0.0,5.0.0), [2.5.0,2.9.0)
> >>
> >> Any drawback to this approach?
> >>
> >> -Guo
> >>
> >>
> >
>
Re: Less restrictive conflict resolution for fragment imports
Posted by "Richard S. Hall" <he...@ungoverned.org>.
What I was planning on doing is taking the intersection, which would be
the highest floor and the lowest ceiling of each overlapping version
range...and of course, if there is no intersection, then they are in
conflict and the fragment would be thrown out.
-> richard
On 12/16/09 11:13, Andreas.Schlosser@sybase.com wrote:
> Guo,
>
> I think your algorithm is not 100% correct. The host version boundaries
> must lie within the fragment version boundaries. So, looking at your
> example:
>
>
>> Host version [2.0.0,3.0.0)
>>
>
>> Fail fragment versions [1.0.0], [1.0.0,2.0.0), [3.0.0]
>>
> Fails, since version lies completely outside host version boundaries
>
>
>> Pass fragment versions
>> [1.0.0,5.0.0),
>>
> Passes, since host version lies within these boundaries
>
>
>> [2.5.0,2.9.0)
>>
> Fails, since host version lies outside boundaries. E.g., when host is
> importing 2.1.0 this would cause fragment to fail.
>
> Thanks,
> Andreas
>
>
> Guo Du<mr...@gmail.com> wrote on 12/16/2009 02:25:50 AM:
>
>
>> On Wed, Dec 16, 2009 at 12:54 AM,<An...@sybase.com> wrote:
>>
>>> Hi,
>>>
>>> I found that Felix is validating the compatibility of host vs.
>>>
> fragment
>
>>> imports by ensuring that in case host and fragment are importing the
>>>
> same
>
>>> package, they should use the exactly same version (range). I believe
>>>
> that
>
>>> this is a little too restrictive and Felix should also allow the host
>>> bundle to be more restrictive on the version range than the fragment.
>>>
> This
>
>>> way, it is still guaranteed that the fragment will run with using the
>>> version range from the host bundle (which is a subset of the fragment
>>> version range in this case).
>>>
>>> I just ran into this problem when trying to use the Hibernate +
>>> Annotations bundles packaged by SpringSource. Hibernate Annotations is
>>>
> a
>
>>> fragment bundle, hosted by the Hibernate bundle. Hibernate imports
>>> org.dom4j;version="[1.6.1, 1.7.0)" whereas the fragment imports
>>> org.dom4j;version="[1.6.1, 2.0.0)" and the current implementation does
>>>
> not
>
>>> allow this fragment to be linked to its host.
>>>
>>> What do you think?
>>>
>> +1
>>
>> I have this problem with spring-osgi-extender as well. For fragment,
>> we may enable the fragment when there are common set between host
>> version and fragment version.
>>
>> Host version [2.0.0,3.0.0)
>> Fail fragment versions [1.0.0], [1.0.0,2.0.0), [3.0.0]
>> Pass fragment versions [1.0.0,5.0.0), [2.5.0,2.9.0)
>>
>> Any drawback to this approach?
>>
>> -Guo
>>
>>
>
Re: Less restrictive conflict resolution for fragment imports
Posted by An...@sybase.com.
Guo,
I think your algorithm is not 100% correct. The host version boundaries
must lie within the fragment version boundaries. So, looking at your
example:
> Host version [2.0.0,3.0.0)
> Fail fragment versions [1.0.0], [1.0.0,2.0.0), [3.0.0]
Fails, since version lies completely outside host version boundaries
> Pass fragment versions
> [1.0.0,5.0.0),
Passes, since host version lies within these boundaries
> [2.5.0,2.9.0)
Fails, since host version lies outside boundaries. E.g., when host is
importing 2.1.0 this would cause fragment to fail.
Thanks,
Andreas
Guo Du <mr...@gmail.com> wrote on 12/16/2009 02:25:50 AM:
> On Wed, Dec 16, 2009 at 12:54 AM, <An...@sybase.com> wrote:
> > Hi,
> >
> > I found that Felix is validating the compatibility of host vs.
fragment
> > imports by ensuring that in case host and fragment are importing the
same
> > package, they should use the exactly same version (range). I believe
that
> > this is a little too restrictive and Felix should also allow the host
> > bundle to be more restrictive on the version range than the fragment.
This
> > way, it is still guaranteed that the fragment will run with using the
> > version range from the host bundle (which is a subset of the fragment
> > version range in this case).
> >
> > I just ran into this problem when trying to use the Hibernate +
> > Annotations bundles packaged by SpringSource. Hibernate Annotations is
a
> > fragment bundle, hosted by the Hibernate bundle. Hibernate imports
> > org.dom4j;version="[1.6.1, 1.7.0)" whereas the fragment imports
> > org.dom4j;version="[1.6.1, 2.0.0)" and the current implementation does
not
> > allow this fragment to be linked to its host.
> >
> > What do you think?
>
> +1
>
> I have this problem with spring-osgi-extender as well. For fragment,
> we may enable the fragment when there are common set between host
> version and fragment version.
>
> Host version [2.0.0,3.0.0)
> Fail fragment versions [1.0.0], [1.0.0,2.0.0), [3.0.0]
> Pass fragment versions [1.0.0,5.0.0), [2.5.0,2.9.0)
>
> Any drawback to this approach?
>
> -Guo
>
Re: Less restrictive conflict resolution for fragment imports
Posted by Guo Du <mr...@gmail.com>.
On Wed, Dec 16, 2009 at 12:54 AM, <An...@sybase.com> wrote:
> Hi,
>
> I found that Felix is validating the compatibility of host vs. fragment
> imports by ensuring that in case host and fragment are importing the same
> package, they should use the exactly same version (range). I believe that
> this is a little too restrictive and Felix should also allow the host
> bundle to be more restrictive on the version range than the fragment. This
> way, it is still guaranteed that the fragment will run with using the
> version range from the host bundle (which is a subset of the fragment
> version range in this case).
>
> I just ran into this problem when trying to use the Hibernate +
> Annotations bundles packaged by SpringSource. Hibernate Annotations is a
> fragment bundle, hosted by the Hibernate bundle. Hibernate imports
> org.dom4j;version="[1.6.1, 1.7.0)" whereas the fragment imports
> org.dom4j;version="[1.6.1, 2.0.0)" and the current implementation does not
> allow this fragment to be linked to its host.
>
> What do you think?
+1
I have this problem with spring-osgi-extender as well. For fragment,
we may enable the fragment when there are common set between host
version and fragment version.
Host version [2.0.0,3.0.0)
Fail fragment versions [1.0.0], [1.0.0,2.0.0), [3.0.0]
Pass fragment versions [1.0.0,5.0.0), [2.5.0,2.9.0)
Any drawback to this approach?
-Guo
Re: Less restrictive conflict resolution for fragment imports
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Yep:
https://issues.apache.org/jira/browse/FELIX-1919
-> richard
On 12/15/09 19:54, Andreas.Schlosser@sybase.com wrote:
> Hi,
>
> I found that Felix is validating the compatibility of host vs. fragment
> imports by ensuring that in case host and fragment are importing the same
> package, they should use the exactly same version (range). I believe that
> this is a little too restrictive and Felix should also allow the host
> bundle to be more restrictive on the version range than the fragment. This
> way, it is still guaranteed that the fragment will run with using the
> version range from the host bundle (which is a subset of the fragment
> version range in this case).
>
> I just ran into this problem when trying to use the Hibernate +
> Annotations bundles packaged by SpringSource. Hibernate Annotations is a
> fragment bundle, hosted by the Hibernate bundle. Hibernate imports
> org.dom4j;version="[1.6.1, 1.7.0)" whereas the fragment imports
> org.dom4j;version="[1.6.1, 2.0.0)" and the current implementation does not
> allow this fragment to be linked to its host.
>
> What do you think?
>
> Thanks
> Andreas
>
>