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.
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 am interested in setting up a development environment for ATG in which changes on class will take effect immediately after the build is done, without restarting server and building again the ear file.
I have searched in the product documentation but the only thing I saw you can configure to load dynamically would be the configuration files section.
Is there any other way of configuring the environment for better productivity?
Use JRebel. That will do dynamic re-loading for java classes, property files and other deployable assets. Great for productivity.
If your purpose is to debug and most of time is getting wasted packing and unpacking the ear, you can always use remote debugging with JBoss and Eclipse, but for major changes like adding a method wont be working in that case. One solution to this is use Java DCEVM which will dynamically update code in the JVM. Its a simple jdk just point your Java_home to this jdk and in debug mode you can add code to you class see changes. Use the below link for more information about DCEVM
https://github.com/dcevm/dcevm
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.
I want to create an automated installer for an Eclipse plugin (i.e. not through the "Update Manager"). My scenario is simple: the user closes Eclipse, drops a downloaded JAR into the dropins folder, starts Eclipse and the rest of the process is automated.
In older Eclipse versions, before the era of P2, Eclipse had (still has) a class called InstallCommand which could be used to install pluings into the currently running platform.
While this still works in Eclipse 3.4 & 3.5, it is not behaving properly: most noticeably, plugins installed that way cannot be automatically uninstalled (it is dimmed).
The JavaDoc claims the InstallCommand is deprecated and should be replaced by a P2 alternative. However, I couldn't find the right tool for the job. There is the P2 director, but it is built for running as a separate application from the command line. It is possible to invoke it from within Eclipse but it is really not cut out for that. For example, progress monitoring and error reporting are not working well.
Does anybody know of a good alternative for that?
Thanks,
Zviki
Dropins seems very close to what you want, especially if they are just downloading jars without the associated metadata (ie the metadata will need to be auto-generated).
You could consider defining a second dropins area to manage yourself. Take a look at ProfileSynchronizer in org.eclipse.equinox.p2.reconciler.dropins, in particular the method createProfileChangeRequest. I expect the uninstall behaviour you don't like is a result of the IInstallableUnit.PROP_PROFILE_LOCKED_IU property being added.
The dropins are reconciled at startup, see the p2.reconciler.dropins Activator.watchDropins(), you can likely do the same from your own bundle to watch another folder.
I suggest to deploy your plugin as an executable JAR. The installer in the JAR should ask for the Eclipse install directory and unpack the plugin in the right place (plus some more checks as needed).
Optionally include a little "watchdog" plugin which doesn't depend on much and just checks that your main plugin loads correctly and displays a useful error message which the user can email to you for support.
According to information in bug 311590 1 which is referenced in the deprecation comment of InstallCommand an alternative is possibly to use P2 operations 2, 3.
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.