Right, so taking a deeper look, it seems that the version dependencies are all fixed early on in the framework's startup during the call to SystemState.resolve(). So, even if I call stop() later on for the 2.0 bundle, it is already wired to other bundles (and will get restarted when a class of its is loaded). So, it looks like calling stop and start in downstream bundles is happening too late. This brings me back to my original solution, which I want to avoid is to get into the framework early enough so that I have control over how the resolving happens.
On Thu, Apr 11, 2013 at 11:08 AM, Andrew Eisenberg <[email protected]>wrote: > 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
