views:

413

answers:

2

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

A: 

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.

Aaron Digulla
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?
zvikico
Ask in the p2 news group and/or open a bug against P2 director?
Aaron Digulla
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.
zvikico
+1 So true :( .
Aaron Digulla
+1  A: 

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.

Andrew Niefer
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).
zvikico
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.
Andrew Niefer
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.
zvikico
@zvikico 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 @ http://stackoverflow.com/questions/1705521/can-i-get-eclipse-3-5-discover-everything-in-the-plugins-dir-w-or-wout-p2)
inger