Tip: debug (and patch at runtime) an installed eclipse

Today I had a problem that occurred only in my installed eclipse but not in my runtime workbench.

How to start eclipse so you can attach a debugger?

You have to add the following to the vmargs: -vmargs -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=9009
The 9009 is used later to attach to eclipse.

How attach to eclipse?

• create a new Debug->Remote Java Application.
  
• Set the port to to 9009 (or whatever you use as the address argument in your eclipse launch)
  
• On the Sources tab add the projects that you want to debug..
  

How to "patch" the running eclipse?

Just modify the code. Actually, I discovered this by accident. My problem was an obvious bug (missing check for null), so I fixed in during the debug session. And the usual eclipse "magic" fixed the bug in my running eclipse. It's the hot code replacement that normally happens. I (falsely) though that would only work when I start a runtime eclipse from within eclipse. But it works in any case.

Now I can fix my running eclipse while I'm normally working. The only downside is, that the two eclipse must use two different workspaces. Too bad.

Here's a flash demo video that shows how to do this step by step.

Help! How to manage multiple (RCP) applications in one installation?

Maybe someone reading my blog can help me. I posted essentially the message below to the equinox newsgroup and the platform newsgroup with zero response. Maybe RCP in the headline will help getting someone to read my post ;-)....

How to restrict the plugins visible to an application?

We have several applications (some of them are headless) that run from within the same eclipse installation. The problem is, that all plugins are visible from the applications. This cause problems, if extensions are used that load plugins that cannot run in the context of the headless application.

To illustrate the problem I use a simple example. A headless application that uses the org.eclipse.core.variables plugin to expand a variable. The org.eclipse.core.variables is UI free and therefore no problem. But some plugins that contribute to the variables plugin are not headless. To illustrate this, I use the ${selected_text} variable that is defined in the org.eclipse.debug.ui plugin. This causes the application to fail.

  public class MyApplicationWithVariables implements IPlatformRunnable {
    public Object run(Object arg) throws Exception {
      IStringVariableManager vm=VariablesPlugin.getDefault().getStringVariableManager();
      String message=vm.performStringSubstitution("Hello ${selected_text}!");
      System.out.println(message);
      return EXIT_OK;
    }
  }

   <extension
         id="HelloWorldWithVariables"
         name="Minimal Headless with variables"
         point="org.eclipse.core.runtime.applications">
      <application>
         <run class="gr.scharf.minimal.headless.MyApplicationWithVariables"/>
      </application>
   </extension>

Is there a way to restrict the plugins visible or loadable to an application?
Or is the only way to have a copy of the installation containing only the "good" plugins?

Michael

How the eclipse update manager could look like...

One of the features I don't like about eclipse is the update manager. A few weeks ago, I looked at different alternatives of eclipse update managers. Today Chris Aniszczyk blogged about the FireFox update manager. Interestingly, a few days ago, I created a small flash video on the FireFox update manager, because I think that shows what a user expects from a simple to use update manager.

One of the central paradigms of eclipse the idea of plugins. However from a user perspective, managing plugins is a nightmare. The eclipse update manager is way too complicated, too slow, not robust enough.

Few weeks ago I bought Eric Evans book "Domain Driven Design". I'll blog about it separately. One of the central ideas is what he calls "ubiquitous language" (e.g. read chapter one). The basic idea is to come up with a language to describe the problem domain, in our case the installation and update of plugins. The language is not only used in conversations but also represented by a formal model. The formal model is implemented in code. You can start reasoning and discuss about the model.

If I look at the eclipse update manager, the model used is a very technical model that is totally implementation centric. It is not a model a user of the update manager can simply understand. I think this is the root of the problem. We have to come up with an update manager domain model that represents the problems and tasks a user of eclipse faces and not a model that is focused on the implementation. The current implementation could be used to implement the user model, but in it self it seem not the right abstraction for users.

The FireFox update manager has an easy to understand domain model that is shown in the UI. There are extensions. An extension has an icon, a description and a set of preferences (yes the preferences of each extensions is available directly from the "Extensions" dialog. In eclipse there's no way to find out what an extension contributes to eclipse. See my blog entry "When seamless integration becomes a nightmare..."). Anyway, hit a simple button to check for updates. It's done in seconds (not minutes like eclipse). Once downloaded, you can update the plugins you want to update.

If you don't like an extension you can select an extension and "Uninstall" it. Something that is not possible with the eclipse update manager. Eclipse is a grow only system -- no way to remove features. Like windows in the old days. Once you have installed a feature there's no way to get rid of it. Only, if you regularly do backups (like I do), you can revert a previous version of eclipse by reverting a backup. But eclipse itself is grow only (*). If you have installed a few features you don't like and you cannot get rid of, you will start thinking twice if you want to install a new plugin. That's very bad for the eclipse ecosystem.

Eclipse must solve the update manager problem soon and provide a simple to use and understandable update manager that solves the problems of eclipse users.

Domain Driven Design could help come up with a update manager domain model that is relevant for eclipse users...

Michael

(*) You could also use separate extension locations for each feature you install and simply delete the location if you want to uninstall the extension. But that's a hack. The update manager (UI) does not even support dropping of extensions. I tried that for a while, but it requires a lot of discipline.