Great, thanks Richard. The Hibernate Annotations stuff is wired properly now for me!
Thanks again, Andreas "Richard S. Hall" <[email protected]> 01/22/2010 12:19 PM Please respond to [email protected] To [email protected] cc Subject Re: Less restrictive conflict resolution for fragment imports I just committed a patch to try to make fragment merging less restrictive by calculating version range intersections for merged requirements. It still requires that everything else be the same pretty much, only versions are allowed to vary. Could someone please test to see if this works for them. I deployed new snapshots or you can build from trunk. Thanks. -> richard On 12/17/09 9:44, Richard S. Hall wrote: > On 12/17/09 9:42, Richard S. Hall wrote: >> On 12/17/09 8:27, Stuart McCulloch wrote: >>> 2009/12/17 Guo Du<[email protected]> >>> >>>> On Wed, Dec 16, 2009 at 5:37 PM, Stuart McCulloch<[email protected]> >>>> wrote: >>>>> So +1 to trying the intersection approach. >>>> Intersection ONLY is not safe for the case: >>>>> Host version [2.0.0,3.0.0) >>>>> [2.5.0,2.9.0) >>>>> Fails, when host is importing 2.1.0 this would cause fragment to >>>>> fail. >>> depends when the intersection was made - if it was done before the host >>> resolved >>> then the host's import range would shrink to the intersection: >>> [2.5.0,2.9.0) >>> and the >>> host plus fragment would not be in conflict. >>> >>> now if you're attaching the fragment to an already resolved host then I >>> believe the >>> resolver would look at the existing wires, not the original range - >>> so if >>> the host was >>> already wired to 2.1.0 then the fragment wouldn't be able to attach >>> dynamically >>> >>> but then this is still correct (afaik) in that you can't dynamically >>> attach >>> a fragment >>> that conflicts with the resolved host (btw, do we support dynamic >>> attachment?) >> >> No, we don't. >> >>>> We may have following condition to enable fragment: >>>> 1. exact version match or >>>> 2. host version range inside all fragments version or >>>> 3. all fragments and host share intersection + dynamic verify the >>>> actual imported version is inside intersection >>>> (p.s. I am not sure "dynamic verify the actual imported version is >>>> inside intersection" is viable or not. If not, we could do at least >>>> step 2 which will help both Andreas's and FELIX-1919 case ) >>>> >>> these still fall under 'intersection' imho (ie. the intersection should >>> apply to the >>> host and fragment) but let's see what Richard's algorithm actually >>> looks >>> like :) >> >> The intersection approach will create a new version range each time a >> fragment is added and the next fragment will be compared against that >> range in bundle ID order. I don't think this will allow for any valid >> cases since we are always making the allowed version range more narror. > > Should say "any invalid cases"..."more narrow"... > > -> richard > >> >> -> richard >> >>> >>>> -Guo >>>>
