2009/12/17 Richard S. Hall <he...@ungoverned.org> > On 12/16/09 12:15, andreas.schlos...@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.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. >>>> >>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > -- Cheers, Stuart
