Thanks Peter and Tom. You're right that I was confusing my terminology. I'll try using a resolverHook. Perhaps using resolverHooks will be more stable than enabling and disabling bundles through PDE's BundleInfo class.
Are there any examples or tutorials on resolverHooks? I've been looking through the equinox/eclipse code base and a bit of a web search, but haven't found anything useful yet. On Thu, Apr 11, 2013 at 12:02 PM, Peter Kriens <peter.kri...@aqute.biz>wrote: > As Thomas indicated, you're confusing wiring and start stop. The wiring is > basically creating a class path for the bundles. Since the java VM is very > picky there is no way you can do anything useful in java before a class can > properly link to its context. Start and stop in OSGi is different. It tells > a bundle to provide its function or not. When you use services this model > makes a lot of sense. > > So you're using in the wrong way. As with any technology it is a bad idea > to go against its intended usage, however close it may seem. If I get your > root requirement then I think the best solution is to create a "management" > bundle. This bundle looks at your property and installs the proper bundle. > This can be done quite easily with the OSGi api and saves some memory as > well. > > Unfortunately, in Eclipse you will then be confronted with the little > problem of starting your management bundle ... > > Kind regards, > > Peter Kriens > > Sent from my iPad > > On 11 apr. 2013, at 20:54, Andrew Eisenberg <and...@eisenberg.as> wrote: > > 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 oniensfor 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 <and...@eisenberg.as>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 <njbartl...@gmail.com>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 >>> <and...@eisenberg.as>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 >>>> <njbartl...@gmail.com>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 <and...@eisenberg.as >>>>> > 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 >>>>>> equinox-dev@eclipse.org >>>>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev >>>>>> >>>>>> >>>>> >>>> >>> >> > _______________________________________________ > equinox-dev mailing list > equinox-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/equinox-dev > >
_______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
