Why is this useful? That’s how packaged Eclipse plug-ins are installed in Fedora (for example). In a nutshell, a directory is dropped into a dropins directory system Eclipse knows about when an RPM is installed (e.g. by using yum). The name dropins kind of makes sense 🙂 When Eclipse is started the next time it checks timestamps on files and directories in those dropin-directories and if something has changed, will try to install them. No problem you say? Not quite. First note that all dropins installed bundles get marked as optional, so no error is reported when dropins reconciliation fails. Here is a scenario: Say the bundle you just installed using yum could not be resolved (for whatever reason), then Eclipse will just omit those unresolved bundles, since they’re optional anyway and just starts with bundles the user had installed previously. This is a problem, since the user thinks the plug-in is installed – the yum installation succeeded, after all – but in fact, the *real* installation happens when Eclipse starts the next time. This really is a very brief explanation of the problem and by no means complete. Take home message: one shouldn’t use dropins but use the p2 director to install Eclipse plug-ins instead.
In any case it’s useful to be able to discover dropins problems and this is what Chris described in his blog post. It’s fairly straight forward. Just create a
.options file in your current working directory, put the following content into it and start Eclipse with:
$ eclipse -debug -consolelog -clean (you might want to consider removing ~/.eclipse as well). The only required option is debug, but the other ones are useful as well.
After that you should see very verbose output which should give you hints as to why some plug-ins don’t show up in Eclipse. Happy debugging!