On 1/27/10 14:25, andreas.schlos...@sybase.com wrote:
Great, thanks Richard. The Hibernate Annotations stuff is wired properly
now for me!

Good to hear. We're planning a Felix 2.0.3 release shortly which will include this fix for the short term. Long term, I am trying to completely re-implement Felix' resolver to address some performance issues (and some other items on my agenda), so I expect fragment merging to happen completely differently in Felix 3.0, but hopefully even more leniently.

-> richard

Thanks again,
Andreas





"Richard S. Hall"<he...@ungoverned.org>
01/22/2010 12:19 PM
Please respond to
dev@felix.apache.org


To
dev@felix.apache.org
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<mrdu...@gmail.com>

On Wed, Dec 16, 2009 at 5:37 PM, Stuart McCulloch<mccu...@gmail.com>
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



Reply via email to