I have an Eclipse plugin and want to stop, uninstall bundles from the Eclipse instance and then refresh. Stop and uninstall is no problem, but the refresh part of the code is now deprecated and I want to find an alternative. Currently I'm doing this through org.osgi.service.packageadmin.
Documentation points to org.osgi.framework.wiring package. And from the JavaDoc org.osgi.framework.wiring.FrameworkWiring.refreshBundles(..) seems to be exactly what I want. But the only class that implements this interface is org.eclipse.osgi.framework.internal.core.PackageAdminImpl, i.e an internal class.
Quite possibly this means my approach is wrong. What is the typical way to dynamically uninstall bundles?
If you read the javadoc description for the FrameworkWiring type, you will see:
The framework wiring object for the framework can be obtained by
calling bundle.adapt(FrameworkWiring.class) on the system bundle. Only
the system bundle can be adapted to a FrameworkWiring object.
Related
From where an eclipse plug in will start?
As for as i know, class which extends abstract class plugin will run first.That class will start the bundle and plug-in.xml file will load.Am i correct?
If i am correct, Please tell me in Plug-in.xml which extension point will execute first and how that is determined ?
It's not as simple as you describe. Most importantly, plug-ins/bundles are initially loaded by the platform without actually executing any code from them. The platform reads and evaluates the bundle manifest plugin.xml in order to know what extension points it uses, but only when one of those is actually invoked (usually triggered by user action) does it execute any code from the plug-in (including instantiating the bundle activator class, which usually is an extension of Plugin).
There are exceptions to this (basically plug-in eager start-up, but that's heavily discouraged), but this is the general concept.
Read more details in the Eclipse wiki, help pages, and API docs.
I have created a eclipse product using product configuration (.product) file. I want to display a dialog before the eclipse splash screen(the product screen) appears for some validation.Since am launching the product from the configuration(.product) file,i dont have an IApplication implementation to do the same.
Usage of startup extension is not useful as the control is given to startup extension only after loading the workbench.How this usecase can be supported ? Any help is appreciated.
Thanks,
Santhosh
The startup extension is the earliest place you could get control because, for performance reasons, your plugin won't be started until the user explicitly requests some action that requires your plugin. If you have to run some validation earlier, your two choices are to modify the base Eclipse code and deliver a modified Eclipse platform with your product or perform the validation when you install your plugin.
For completeness, I'll also note that some repackagers of the Eclipse platform (IBM Rational comes to mind. Others have done this, too) have at times included a licensing component that you might be able to plug in to.
This blog describes how to add a login-dialog as part of the splash-screen. Is this what you want to accomplish?
Considering that I am developing an end-user software program (as an uberjar) I am wondering what my options are to make it possible for the user to download a plugin and load that during runtime.
The plugin(s) should come compiled and without source code, so sth. like load is not an option.
What existing libraries (or ways of Java...?) exist to build this on?
EDIT: If you are not sure I would also be satisfied with a way that costs a reboot/-start of the main-program. However, what is important is that the source-code won't be included in any JAR file (neither main application nor plugin-jars, see :omit-source of Leiningen documentation).
To add a jar during runtime, use pomegranate which lets you add a .jar file to the classpath. Plugins of your software should be regular Clojure libs that follow certain conventions that you need to establish:
Make them provide (e. g. in an edn) a symbol to an object implementing a constructor/destructor mechanism such as the Lifecycle protocol in Stuart Sierras component library. In runtime, require and resolve that symbol, start the resulting object and hand it over to rest your programs plugin coordination facilities.
Provide a public API in your program that allows the plugins to interact with it in ways that you coordinate asynchronously e. g. with clojure.core.async (don't let one plugin block the entire program).
Make sure that the plugins have a coordinated way to expose their functionality to each other only if they desire so to enable a high degree of modularity among your plugins. Make sure that your plugin loader is capable of detecting dependencies among plugins and is capable of loading and unloading them in the right order.
I've not tried it myself, but you should in theory be able to get OSGi to work with Clojure.
There's a Clojure / OSGi integration library here:
https://github.com/aav/clojure.osgi
If I were to attempt to role my own solution, I would try using tools.namespace to load and unload plugins. I'm not entirely sure it will work, but it's certainly in the right direction. I think one key piece is that the plugin jars will have to be "installed" in a location that's already on the classpath.
Again, this is only the start of one possible solution. I haven't tried doing this.
I got a little problem. I want to use hibernate in an eclipse rcp. (i'm new to osgi and eclipse rcp). So I added the jar into the plugin-project folder and the build path and the bundle build path, but when I try to use hibernate from my bundle, it crashes with a ClassNotFoundException.
What is the proper way to do this?
Pls look at eclipse buddy policy. This might help you if you are facing class not getting loaded because of osgi classloading.
Hibernate, and many other classic Java programs (ab)use dynamic class loading to to connect the different parts. They classes they use are read from a file and then loaded with Class.forName. This is fundamentally not-modular since these classes are by definition implementation classes, which should be hidden.
Since OSGi is a modularity framework it puts fences around a module (a bundle) and refuses to load anything that is not properly exported and imported. So if Hibernate does its Class.forName it will run right into this fence, as it should be to get the advantages of modularity.
Eclipse Buddy policy is like a huge hole in this fence, moving things back tot he bad old classpath: linear search. With a buddy policy, Eclipse will just start searching if there is a class somewhere that has that name. Since this ignores versions, you can no longer rely on proper version handling. The good news is that it works most of the time. The bad news is that you loose privacy and when it does not work you get weird errors.
With Hibernate, only solution is to not use the text file setup but use the API and give Hibernate the actual classes. In those cases Hibernate will use the class loader of those classes and that works. In OSGi, as long as you follow the Java language rules there are no problems.
To handle the kind of problems that class loading hacks address OSGi uses services.
This is my situation: We have a third party feature in our Eclipse environment. The feature contains several plugins. The plugin contains a bunch of classes. One of the classes contains a bug.
We have been able to find a solution to the bug, so we have a working version of the class with the bug.
Unfortunately this plugin is covered by a 55 page long EULA (by IBM) so I think it's pretty safe to assume that decompiling the jar, exchanging class files, recompiling and distribute is legally out of the question. I'm no legal expert, but I'd guess we cannot tamper with the jar files in any way.
So this means I have a single class file that I want to be loaded instead of a class in a plugin, is this at all possible?
This page suggests using fragments, but this requires modifying the manifest in the plugin.
This question has the same problem as me, but in that case there is access to the source code and he is able to build a plugin.
This blogpost shows how use feature patches, but they require that I'm able to build my own plugin, which I cant since I have just the one class.
I would not try using a fragment. In my experience, the cleanest thing to do would be to use a feature patch. I have successfully used feature patches to do exactly what you are looking to do. It's not simple, but it is robust. You need to do the following.
create a plugin that encapsulates your single class file
create a feature patch that includes your new plugin and that patches the feature that you are targeting.
export your feature patch and create the p2 metadata (to create an update site).
Install into your Eclipse using the install manager
Rejoice!
(optional) Feature patches by default only target a single version of the target feature. So, if the target feature bumps up its version number, the feature patch will silently no longer be applied. However, it is possible to relax the version constraints on the feature patch. This process is described in detail here: http://aniefer.blogspot.com/2009/06/patching-features-part-2.html
More information:
http://aniefer.blogspot.com/2009/06/patching-features-with-p2.html
http://aniefer.blogspot.com/2009/06/patching-features-part-2.html
The benefit of using a feature patch over a fragment is that anyone can install the patch and get the patch working, but things are more difficult with a fragment in that end users must muck with manifests.
So this means I have a single class file that I want to be loaded instead of a class in a plugin, is this at all possible?
Your first sentence is the answer. You can use a fragment, but that requires modifying the manifest in the plugin. Otherwise, Eclipse would have no idea which class to load.
My suggestion is that you write IBM with all of this information, including the patch. IBM should be able to release a maintenance fix which would solve your problem.
In the mean time, you could pursue the fragment option, which would require you to unpack the jar, add your fragment, modify the manifest, and repackage the jar. Whether or not this is legal is beyond my ability to determine.