On 12/16/09 11:48, andreas.schlos...@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.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
