Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 118520

Summary:

Problem with resolver resolution algorithm

Product:

[Eclipse Project] Equinox

Reporter:

DJ Houghton <dj.houghton>

Component:

Framework

Assignee:

Thomas Watson <tjwatson>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

jeffmcaffer, zhouyiy

Version:

unspecified

Target Milestone:

3.2 M4

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
example plug-in	none
Possible fix	none
Fix with no fragment consideration	none

Description DJ Houghton

2005-11-29 16:51:30 EST

build i1102

I built a test which creates bundle description objects and dependancies. I resolved this state and then added new versions to the state and resolved again. I expected the resolver to pick the versions of the bundle which satisfied the most requirements, but that was not the case.

Consider the following example:

"SDK 1.0" requires "Platform" [1.0,2.0].
"Platform 1.0" requires "RCP" [1.0,2.0].
"RCP 1.0" requires nothing.
"GEF 1.0" requires "RCP" [1.0, 1.0].

resolve.

add new versions:

"SDK 2.0" requires "Platform" [2.0,2.0].
"Platform 2.0" requires "RCP" [1.0,2.0].
"RCP 2.0" requires nothing.

resolve.

I would expect Platform 2.0 to be resolved and SDK 2.0 and RCP 2.0 not to be, since that would break GEF 1.0. Instead, all 1.0 bundles are unresolved.

Will attach example.

Comment 1 DJ Houghton

2005-11-29 16:52:09 EST

Created attachment 30812 [details]
example plug-in

Example plug-in which contains the code to create the bundle descriptions.

Comment 2 Thomas Watson

2005-11-29 19:18:44 EST

The selection algorithm is not working as expected here.  We use the dependents from BundleDescriptionImpl to track the use count.  This is used to determine the singleton which should be selected based on which one is used the most.

The problem is the dependents list in BundleDescriptionImpl is not the right thing to use in this case.  This is because the dependents list only keeps track of the dependents which actually got wired to a particular bundle.  It does not keep track of all the "possible" bundles which MAY get wired to a paarticular bundle.

I will attach a possible solution to this problem.

Comment 3 Thomas Watson

2005-11-29 19:20:59 EST

Created attachment 30820 [details]
Possible fix

DJ, can you test this patch out for your scenario.  Thanks.

Comment 4 DJ Houghton

2005-11-30 09:53:30 EST

This gives me the expected results. In my case, SDK 2.0 and Platform 2.0 are resolved but RCP 2.0 is not because it doesn't satisfy GEF 1.0.

Comment 5 Thomas Watson

2005-11-30 16:56:21 EST

Created attachment 30904 [details]
Fix with no fragment consideration

The last fix used a selection policy which included fragments.  So if one version of a singleton bundle caused more fragments of that singleton bundle to resolve then it was picked.

This is not desired because fragments are considered add-ons and cannot be required by other bundles.  This new patch uses a selection policy which only considers Import-Package and Require-Bundle to decide which version of a singleton bundle to select.

Comment 6 Thomas Watson

2005-11-30 18:01:43 EST

Fixed in HEAD for 3.2.  I also added 4 new resolver testcases to cover the singleton selection policy.

Comment 7 Yi Yan Zhou

2007-05-08 22:31:36 EDT

(In reply to comment #6)
> Fixed in HEAD for 3.2.  I also added 4 new resolver testcases to cover the
> singleton selection policy.
> 

Do you have the fix for 3.1.1? We really need that fix. Or can you show me the dependency changes needed by this fix? So I can create my own fix according to your help. Thanks!

Comment 8 Thomas Watson

2007-05-10 16:43:51 EDT

This was fixed in 3.2.2.  No fix was provided in the 3.1 stream.  Is there any way you can move to 3.2.2?

I may be able to provide a backport to 3.1.x but the resolver changed a lot between 3.1 and 3.2.  The port will not be easy and will not be well tested.

Comment 9 Thomas Watson

2007-05-10 16:44:56 EDT

Opps, I meant the fix went in 3.2.0.