How to restrict the plugins visible to an application?
We have several applications (some of them are headless) that run from within the same eclipse installation. The problem is, that all plugins are visible from the applications. This cause problems, if extensions are used that load plugins that cannot run in the context of the headless application.
To illustrate the problem I use a simple example. A headless application that uses the
org.eclipse.core.variables plugin to expand a variable. The org.eclipse.core.variables is UI free and therefore no problem. But some plugins that contribute to the variables plugin are not headless. To illustrate this, I use the ${selected_text} variable that is defined in the org.eclipse.debug.ui plugin. This causes the application to fail.
public class MyApplicationWithVariables implements IPlatformRunnable {
public Object run(Object arg) throws Exception {
IStringVariableManager vm=VariablesPlugin.getDefault().getStringVariableManager();
String message=vm.performStringSubstitution("Hello ${selected_text}!");
System.out.println(message);
return EXIT_OK;
}
}
<extension
id="HelloWorldWithVariables"
name="Minimal Headless with variables"
point="org.eclipse.core.runtime.applications">
<application>
<run class="gr.scharf.minimal.headless.MyApplicationWithVariables"/>
</application>
</extension>
Is there a way to restrict the plugins visible or loadable to an application?
Or is the only way to have a copy of the installation containing only the "good" plugins?
Michael
The only way I know you can share the same install between two or more apps is by crafting multiple configurations, one per application. You can then enable only the features you want for each product, so it will be like any plug-ins belonging to the other (disabled) features do not exist. Running a product will require the specific configuration area to be informed.
ReplyDeleteI believe Jeff & JM's book covers this scenario, but I am not sure, because I don't know of any supported way of crafting platform configurations (other than the IPlatformConfiguration API).
The other thing I wanted to comment on is that it is a design smell when you have UI plug-ins that are activated (and fail) when non-UI executable extensions are instantiated. If you own them, you should fix them.
For some reason, EclipseZone doesn't seem to have picked up your post (otherwise I'm sure I'd have seen it there).
ReplyDeleteThe update configurator in an Eclipse app just scans through all the plugins in a plugins/ directory and Bundle.install()s them (or similar). If you don't have this line, then you only have a small number of bundles when the osgi framework starts.
To solve this problem, if you know what the set of bundles are for your app, you could install them individually by writing your own equivalent of the update configurator to just install yours. So rather than having the UI bundle in the resolved state, it wouldn't even be installed and thus any extension points it contributes wouldn't be displayed.
You could also do the same trivially by expanding the list of known bundles for your app and listing them individually on the config.ini without any code changes.
Like the other poster says, you'll need to have one config.ini for each application for this to work.
Alex.
The is exactly the scenario that SAS uses for its RCP apps. We install one rcp and several apps. Each app points to the rcp for the base install and then to second area for Eclipse supplied plugins and then on to the app supplied plugins. That second area is segregated up into individual extension locations and a platform.xml is hand crafted for each app to only choose the plugins that that particular app wants to expose. This is fragile but it works. Our next generation of app install, however, will use the osgi.bundles property in config.ini to select the plugins each rcp app requires. This allows us to throw all the plugins together into one area instead of 3 areas and not have to worry about controbution bleed through.
ReplyDeleteGreat readinng
ReplyDelete