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

Bug 281148

Summary: Get rid of org.eclipse.e4.services extension point
Product: [Eclipse Project] e4 Reporter: John Arthorne <john.arthorne>
Component: UIAssignee: John Arthorne <john.arthorne>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: bokowski, ob1.eclipse
Version: unspecified   
Target Milestone: 0.9 M4   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Fix
none
Test cases none

Description John Arthorne CLA 2009-06-22 16:54:24 EDT 
The org.eclipse.e4.services extension point is used as a way to generically contributed IContextFunctions so they can be used in components created in other bundles. There are some problems with this approach:

 - It is not lazy. The extension point gives the impression of lazy loading, but in fact the functions are loaded eagerly so they can be added to the context
 - It is not dynamic. You could theoretically withdraw a service by shutting down the bundle providing the extension, but there is no link to all the contexts that may be using the service at time of removal
 - Anybody wanting to use these contributed functions needs to write the wad of code to walk the extension registry and add the functions to their context
 - It has no arbitration mechanism to deal with multiple bundles providing the same service

In short, this extension point is a poor man's version of OSGi services without all the well thought solutions to the problems of laziness, dynamicity, service arity, etc.

Given that contexts now support OSGi services, we should transition away from the services extension point towards a pure OSGi service model.
Comment 1 John Arthorne CLA 2009-06-22 17:10:00 EDT 
I've been chipping away at this for a few months, but I'm nearly done.
Comment 2 John Arthorne CLA 2009-06-22 17:28:48 EDT 
Created attachment 139813 [details]
Fix

I was able to remove most users of the services extension point by simply registering OSGi services instead. However, there were a few remaining cases where something extra was needed:

 - In some cases we want a factory that returns a different value on each lookup
 - In some cases we want to use information in the context to help us supply a service value (e.g., EContextService)

These cases are supported in this patch by allowing bundles to declare IContextFunction instances as services. A service property specifies the "key" to be used when adding that function to a context. The OSGiContextStrategy consults context function services during its lookup. Adding support for this literally took three lines of code!
Comment 3 John Arthorne CLA 2009-06-22 17:30:42 EDT 
Created attachment 139814 [details]
Test cases

Adding some test cases that use declaratively registered context functions. This gives true lazy activation because the DS component will only be activated when the service is obtained.
Comment 4 John Arthorne CLA 2009-06-22 17:33:18 EDT 
Released to head. Also released:

 - Fixed e4photo demo to use DS component rather than services extension point. Lazy activation strictly needed here, but I wanted a simple "best practices" example of how to combine all the pieces in the demo.

 - Removed code in e4.ui.workbench that seeded the main context with functions defined by services extension point.