felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Less restrictive conflict resolution for fragment imports
Date Wed, 16 Dec 2009 17:03:37 GMT
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<heavy@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<mrduguo@gmail.com>   wrote on 12/16/2009 02:25:50 AM:
>>>
>>>
>>>
>>>        
>>>> On Wed, Dec 16, 2009 at 12:54 AM,<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?
>>>>>
>>>>>
>>>>>            
>>>> +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
>>>>
>>>>
>>>>
>>>>          
>>>
>>>        
>>      
>    

Mime
View raw message