Programatically installing an Eclipse plugin from within Eclipse?

Question

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

Vandervelde

Usually unpacking the features and plugins in a folder under dropins should be enough to install a plugin. What else do you want to do? – Yalta

True. However, I have a commercial plugin and I'm trying to create a more user friendly experience. Dropping it into the dropins folder may fail error reporting is less than obvious in this case. Not all Eclipse users are Eclipse experts that can track down the problem and solve it. – Vandervelde

If you're doing your own thing in installing, you're probably better off doing your own thing with upgrading, as well. – Tractor

@Al, no, I don't. Eclipse update mechanism will do. Here's the thing: when people visit your site and decide they will try your software, they want to download. Something. In most cases they don't install it right away but later on. If you leave them with just an update URL, you are loosing customers, guaranteed. That's why a download and an installer is important. I should blog about this... – Vandervelde

Answer 1

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.

Rodmun

Thanks. I am not looking to replicate the dropins behavior. Regarding the PROFILE_LOCKED - it is not something I did, so it could be a bug (though I doubt anybody will bother fixing it at this stage). – Vandervelde

The PROFILE_LOCKED is in the current p2 code, I know it is there on purpose, but I'm not sure of the reasons behind it. – Rodmun

I will go for dropins solution for now (works in most cases), but I can think of better suggestions. Something like a JAR but with a different suffix (like EAR or WAR, could be OAR for OSGi). It will be associated with Eclipse so a double-click will invoke Eclipse. It will either pack an update site, contain a URL to an update site or an executable to be invoked in the current OSGi running framework. I'll organize my thoughts and open an issue to suggest it. – Vandervelde

@Vandervelde This OAR idea sounds interesting (similar to many packaging solutions). Have you raised a bug for it? Also, when you said 'not looking to replicate the dropins behaviour' - what did you actually mean? The main difference is, you would have some UI with progress bars and stuff? (which I think would be great for stock P2 as well..but who knows it seems the dropins mechanism is already deprecated (see a bug @ #1706021) – Flowerpot

Answer 2

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.

Yalta

It's a good option, I considered it myself. However, you would still need to perform a provisioning action on the target platform. You should not assume a standard plugins/features directory structure, but rather let P2 handle the installation. This brings you back to square one... How? – Vandervelde

Ask in the p2 news group and/or open a bug against P2 director? – Yalta

It's a possible enhancement for the P2 director. I might suggest it. As for the P2 group: I simply like StackOverflow far better and I usually get more answers here then there. Most of the questions I asked in the Eclipse newsgroups were left untouched. – Vandervelde

Answer 3

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.

Aramenta