I have an existing Eclipse plugin which run as a regular IDE plugin, receiving commands from the GUI and returning output in custom views.
I want to add an ability to also be able to run that plugin in headless mode, with the input received from the command-line and the output going to some file. Is there some way of modifying the existing plugin to support that mode of execution in addition to the existing regular execution, or do I have to create a new headless plugin and just use code from the first one?
It depends on how you plan to use this plugin and the main question: is there a case, where your UI dependencies will not be available, i.e. whether there is a bundle configuration without SWT and RCP bundles?
No UI available
In this case, you'll need to extract the headless part of your plugin into new plugin, which then registers the headless entry point to it. The UI part of the plugin will depend on the new plugin and just delegate UI requests to the appropriate API in the headless part.
In order to provide headless application, you should take a look at org.eclipse.equinox.app.IApplication interface and respectively org.eclipse.equinox.applications extension point. When you've defined the application, you launch it by simply invoking:
eclipse -application <app-id> <app-param>
More information can be found in Eclipse Help.
UI available
The simpler case. Only the headless entry point needs to be specified and everything will work as previously.
My experience, however, shows that sooner or later, the case arise where the plugin needs to be split and depending on its complexity it might cause more trouble than it would have been if it was split earlier.
Related
We are developing an Eclipse RCP application, and up to target version 2022-03, we always used this to get the current workspace path:
ResourcesPlugin.getWorkspace().getRoot().getLocation().toString()
But: with Eclipse target version 2022-09, we get an IllegalStateException, if we run the product outside of eclipse, i.e. the exported product:
java.lang.IllegalStateException: Workspace is already closed or not ready yet. Consider tracking the org.eclipse.core.resources.IWorkspace service (using your favorite technique, e.g. Declarative Services, ServiceTracker, Blueprint, ...) instead of calling the static method here to prevent such issues!
at org.eclipse.core.resources.ResourcesPlugin.getWorkspace(ResourcesPlugin.java:502)
I mean, the exception does propose some alternatives. But: is it really not possible anymore to use ResourcesPlugin.getWorkspace()? This was quite convenient. Is there any equally simple solution?
The simplest way of getting the workspace location is:
URL location = Platform.getInstanceLocation().getURL();
Platform is org.eclipse.core.runtime.Platform.
This does not rely on the resources plug-in at all (so it even works in a e4 RCP without the resources plug-in).
I'm working on a project developing an Eclipse-based application. Running a JUnit plug-in test requires the run configuration for it to have a bunch of parameters set. This means that if I want to run a single test class or method, as far as I can tell I have to create a new configuration or edit one that I reuse. More annoyingly I can't use the convenience of Alt+Shift+X, P.
Is there a way to tell Eclipse that a bunch of parameters are the defaults for an implicitly created run configuration of a given type to use it when it's automagically creating one?
If you are using a custom target platform (which you should use anyway), you can specify Program arguments and VM arguments on the Environment tab of the target platform editor.
They will be used as default values for PDE launch configurations.
I'm working on an Eclipse rcp application which is using a middle layer to request data. I want to run my application in offline mode i.e. if data service is not available I should be able to work on some dummy data. For this purpose I want to exclude/ include extensions (not extension points but extension point providers). Is that possible?
Thanks
If you put the live and test versions of the extension point implementation in different plugins you can then choose which plugins to include in the product build - so you would have two product configurations, one for testing and one for production. When you are testing in Eclipse you can configure the plugins to include in the Run Configuration, so again you would have a test and production configuration.
It might also be possible to use a plugin fragment to contain just the part which varies. Use New / Project / Plug-in Development / Fragment Project to create.
I have deployed some Eclipse plugins and I want them to take effect without restarting the Eclipse environment. Is it posssible?
At a pure OSGi level, you would use
BundleContext.installBundle()and then PackageAdmin.refreshPackages(), and if necessary, perhaps Bundle.start().
How well this works in your running system will depend on how your bundle is being used by the rest of the system, and how things will react when an old version goes away and a new one appears.
Take a look at these 2 faq entries from the wiki:
How do I make my plug-in dynamic aware?
How do I make my plug-in dynamic enabled?
To do this at a higher level, you would take a look at p2.
Yes, it is. OSGi (and Eclipse is OSGi based) provides a way for dynamic bundle loading without the need to restart the environment. However, eclipse suggest a restart because it works in 100% of the cases, while it cannot guarantee that all plugins will be properly written. You have probably seen the "Apply changes" button after installing a plugin - this tries to reload it without restart.
Anyone know of a way to guarantee plugin startup order? I have a plugin that I want to develop that will provide runtime configuration information to a 3rd-party plugin that I can't modify.
So, I want to make sure my plugin always runs to completion before the 3rd-party.
Eclipse 3.3, BTW.
The OSGi way to do it is to use start levels in config.ini. But for Eclipse plugins they typically aren't listed there but are automatically configured by the configurator bundle.
Honestly you're not really supposed to do this. OSGi bundles (which means, Eclipse plugins) are supposed to be able to be started in any order, in general. Use the service registry to get handles to whatever you need as soon as they become available.
Another way to look at it: what's causing the 3rd-party plugin to load (since Eclipse favors lazy loading of plugins)? Perhaps you can hook into the same mechanism.
If you get desperate you can force yourself to be started using the Eclipse startup extension point. Just remember that a) this is the nuclear option, b) the user has UI under Preferences to turn off your startup extension, c) you don't get to control the ordering of the startup extension point, so if your 3rd-party plugin uses it too, you are SOL.
Check out start level or start level service.
Though it seems it is not quite straightforward to use in Eclipse.