Re: Less restrictive conflict resolution for fragment imports

[Richard S. Hall]

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.schlos...@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<mrdu...@gmail.com>   wrote on 12/16/2009 02:25:50 AM:



       
On Wed, Dec 16, 2009 at 12:54 AM,<andreas.schlos...@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