I think you are mixing up resolving with starting. Resolution wires get created when a bundle is resolved, not started. There are two ways to prevent a bundle from resolving:
1) Don't install the unwanted bundle. 2) Use resolver hooks to disable the bundles you don't want to allow to resolve 2 is actually pretty hard to achieve without timing issues. Your checker bundle would have to come up and notice that the unwanted bundles are resolved, it then could decide to register a ResolverHook that prevents the unwanted bundle from resolving and then for a refresh of the unwanted bundle. This would force the unwanted bundle into the INSTALLED state, but would also force any bundles that were wired to the unwanted bundle to get refreshed and potentially re-resolved against the bundles you want. Or you could just uninstall the bundles you don't want and refresh. Tom From: Andrew Eisenberg <[email protected]> To: Neil Bartlett <[email protected]>, Cc: Equinox development mailing list <[email protected]> Date: 04/11/2013 01:12 PM Subject: Re: [equinox-dev] Choosing which version of a bundle to start after the workbench starts Sent by: [email protected] OK. Just tried something like this. The problem is that by the time the downstream bundle gets into its start method, and tries to stop all of the unwanted versions of the non-singleton bundle, a bunch of wiring has already been done. And there are other bundles out there that have already wired themselves to the 2.0 version instead of the 1.8 version. I'll dig a bit deeper to see if this is just a matter of timing (ie- maybe I'm choosing the wrong downstream bundle to execute stop() in). On Thu, Apr 11, 2013 at 10:49 AM, Neil Bartlett <[email protected]> wrote: Bundle version 2.0.0 will only be started if somebody explicitly starts it, or if it has already been put into the persistently-started state, or if it is listed in config.ini with @start. If you're unsure of the current persisted state of all the bundles, your "starter" bundle should probably explicitly stop ALL versions before transiently starting the selected version. Neil On Thu, Apr 11, 2013 at 6:42 PM, Andrew Eisenberg <[email protected]> wrote: Thanks, Neil. I'll have to try this to make sure, but starting the bundle that I want doesn't prevent the bundle I don't want from starting. Eg- if I want version 1.8.6 and I call start(START_TRANSIENT) on it, I think the 2.0.0 version will still be started. I'll try this to make sure, though. On Thu, Apr 11, 2013 at 10:22 AM, Neil Bartlett <[email protected]> wrote: Why not start the bundle transiently (ie. Bundle.START_TRANSIENT) from another ordinary bundle? Since the target bundle's start-state is not persisted, you will be able to decide each time which bundle to start. Neil On Thu, Apr 11, 2013 at 6:18 PM, Andrew Eisenberg <[email protected] > wrote: Hi all, I have multiple versions of a bundle installed in my Eclipse installation. After the workbench starts up, I need to make a decision as to which version of the bundle should be started based on a system property that the user passes in from the command line. Currently, I am doing this through a framework adapter that adds a BundleInfo to disable/enable appropriate versions of the bundle as the workbench starts up, but this is brittle and has limitations. This bundle is not a singleton and all downstream bundles depend on a version range that includes all possible candidates of this bundle. So my question is: is there any way to control which version of the plugin starts without using BundleInfos? I can provide more details if you need. thanks for your help, Andrew _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<inline: graycol.gif>>
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
