felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas.Schlos...@sybase.com
Subject Re: Less restrictive conflict resolution for fragment imports
Date Wed, 16 Dec 2009 16:13:29 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message