Replace manual activateProxyService() with declarative Require-Capability on IProxyService?

[vogella]

IDEWorkbenchAdvisor.activateProxyService() (in org.eclipse.ui.ide.application) eagerly fetches IProxyService via OSGi BundleContext.getService(...) purely to force activation of org.eclipse.core.net.

The returned service is never used; the variable exists only to trigger the side effect.
If the lookup fails, the result is a logged warning that is easy to miss.

The same activation can be expressed declaratively in META-INF/MANIFEST.MF:

  Require-Capability: osgi.service;                                                                                                                                                                                                             
    filter:="(objectClass=org.eclipse.core.net.proxy.IProxyService)";
    effective:="active"                                                                                                                                                                                                                         

This is the modern OSGi pattern and is already used in this repository for EventAdmin in org.eclipse.e4.ui.workbench and org.eclipse.e4.ui.services.
Benefits

• Removes ~15 lines of imperative activation code (activateProxyService() and its call site in postStartup()), including the awkward Object proxyService assigned-but-unused variable.
• Dependency becomes visible in the manifest alongside other declared capabilities.
• A missing IProxyService provider becomes a hard resolution failure at startup instead of a runtime log line, which is the more useful failure mode for the IDE.
• No measurable runtime cost change — both paths end up activating org.eclipse.core.net in the same way.

[tomaswolf]

See also eclipse-egit/egit#118 !

effective:="active" is not defined in the OSGi specification: https://docs.osgi.org/specification/osgi.core/8.0.0/framework.module.html#d0e3015 So where is that defined and what does it mean?

Note that bundle org.eclipse.core.net does not activate this service, and even has a flag (system property org.eclipse.net.core.enableProxyService [SIC! Note "core.net" in the bundle name vs. "net.core" in the property name]) that disables this service altogether. If set, the service isn't even registered.

[laeubi]

effective:="active" is not defined in the OSGi specification

This is not entirely true see

• [core] explain effective:=active value in the spec text osgi/osgi#803
• https://github.com/osgi/osgi/blob/19378f170291be6d36f02beb0f444940fe688340/org.osgi.resource/src/org/osgi/resource/Namespace.java#L141

It is just not used at runtime (only a resolve time convention for tools)

[tomaswolf]

This is not entirely true

OK, so the draft for the next OSGi release mentions it. The latest official release is 8 AFAIK, and that doesn't mention it. And anyway it seems to mean "if you want to activate this bundle, you may do so only if this requirement is already activated".

So what activates bundle org.eclipse.core.net and registers the service if IDEWorkbenchAdvisor.activateProxyService() is not there?

Our experience from the linked EGit issue was: nothing. The org.eclipse.core.net bundle is not activated and the proxy service is simply not there.

In EGit we went back from using declarative service injection to using a ServiceTracker. That works since we then reference class IProxyService, which causes activation of the org.eclipse.core.net bundle even if there is no IDEWorkbenchAdvisor.

[laeubi]

OK, so the draft for the next OSGi release mentions it. The latest official release is 8 AFAIK, and that doesn't mention it.

It only mention it in the javadoc. Anyways this is a common used thing all over the place and the spec explicitly says custom values are allowed.

And anyway it seems to mean "if you want to activate this bundle, you may do so only if this requirement is already activated".

As mentioned it has nothing to do with runtime, OSGi ignores all but resolve (and activation is a complete different topic).
This is more a hint to a management agent (e.g. P2 or bnd-resolve) that your component (even though resolving) will likely need more things. e.g. an implementation for a service.

In EGit we went back from using declarative service injection to using a ServiceTracker

Using DS or ServiceTracker does not make a difference both require a service and it will be (possibly) created depending on how it is provided.

There might be subtile difference in how people use it that leads to activation of (lazy) bundles that are decoupled by service interfaces. No requirement in the bundle can ever affect this and it is more affected in by how org.eclipse.core.net works.