Community
Participate
Working Groups
Bug 323296 and bug 326011 have introduced a mechanism for adding ResolverHooks to the equinox framework which allows clients to influence the resolution of bundles. From the javadoc of org.osgi.framework.hooks.resolver.ResolverHook: "A resolver hook may influence the outcome of a resolve process by removing entries from shrinkable collections that are passed to the hook during a resolve process." This mechanism is not available currently when resolving is driven by PDE's BuildTimeSite. It would be great if pde build could be aligned with the runtime behavior. Specifically, a ResolverHook could be used for a potential solution for bug 330534. In that particular context I observed that for two different versions of a plugin two inconsistent selections are made in different places: - selection of a single version if the bundle is a singleton -> picks version with most incoming references - selection of the appropriate host for a fragment -> picks highest version This inconsistency can cause incomplete classpaths. It could be remedied by a ResolverHook. I see the following difference between runtime and buildtime behavior: At framework start the following lines initialize the State: framework.adaptor.frameworkStart(bc); State state = framework.adaptor.getState(); if (state instanceof StateImpl) ((StateImpl) state).setResolverHookFactory(new CoreResolverHookFactory((BundleContextImpl) context, framework.getServiceRegistry())); As soon as the State is initialized it is connected to a hook factory, which will obtain references to client provided ResolverHookFactories from the service registry. At buildtime, however, creation of a PDEState fails to connect the newly created State to any ResolverHookFactory. This factory should be obtained from the service registry, too. If there are no objections against this enhancement I will prepare a patch.
My biggest concern would be relying on internals to initialize this. Are there any default ResolverHooks that would change the behaviour when running with a normal SDK or releng.basebuilder?
(In reply to comment #1) > My biggest concern would be relying on internals to initialize this. You mean the necessity to call StateImpl.setResolverHookFactory() ? > Are there any default ResolverHooks that would change the behaviour when > running with a normal SDK or releng.basebuilder? At this point I don't know about any implementations of ResolverHook (aside from the delegating CoreResolverHookFactory). I assume that as soon as (more) people use the new API some will eventually need consistent support also during build. But given that bug 330534 no longer depends on this RFE I personally wouldn't mind if you close as WONTFIX.
(In reply to comment #2) > (In reply to comment #1) > > My biggest concern would be relying on internals to initialize this. > > You mean the necessity to call StateImpl.setResolverHookFactory() ? > This, and that CoreResolverHookFactory itself is also internal. We can see what Tom says about this, I believe he is on vacation this week.
I do not want to expose this hook for the State at this point. I would prefer to keep the setting of the resolver hook in the state as an internal detail for now.
(In reply to comment #4) > I do not want to expose this hook for the State at this point. I would prefer > to keep the setting of the resolver hook in the state as an internal detail for > now. Alright, in that case and given that the original motivation has gone, I'm withdrawing this RFE for now.
