Much ado about scripting, Linux & Eclipse: card subject to change


Managing Plugins and Features with Link Files and Extension Locations

After loitering and latering (but no lootering!) in IRC for a few hours today, I've come to the conclusion that not enough people know about .link files. I guess I could wiki this, but I thought I'd blog it instead.

Scenario 1: You're an Eclipse user. You use Eclipse a lot. In fact, you use multiple versions of Eclipse for testing, debugging, and even *gasp* developing. You waste a ton of time unpacking zips and running Update Manager.

Scenario 2: You use Eclipse and occasionally do something silly like deleting files outside of Eclipse or updating CVS files using commandline CVS instead of the click-click-wait method in Eclipse. (This is usually not a problem, but can sometimes lead to ...)

Scenario 3: Something Wicked This Way [Came] and your Eclipse has become corrupt. It's time to blow away your config files, .metadata files, or run with -clean. If that doesn't work you probably have to reinstall (oh crap) everything -- Eclipse + all your trusty plugins. You could also copy carefully from the busted Eclipse to the minty-fresh one, but that's both time consuming and possibly dangerous. Is there a better way?

Scenario 4: You produce a product based on Eclipse but want to keep your stuff and Eclipse's stuff separate when you bundle it all up for easier digestion by your users. Maybe for license reasons, maybe for legal reasons, maybe just for file system hygiene or to make support easier.

Scenario 5: You're a control freak and just like to keep stuff in different places according to your own particular... um... idiom.

In all of these scenarios, .link files can help. Here's how to set one up:

  1. In your Eclipse install folder, create a links/ folder next to features/ and plugins/.
  2. In your eclipse/links/ folder, create a textfile called This file need only be one line, with newline and no trailing slash(es), and can be called anything ending with .link.
  3. Unpack a zip full of plugins and features into the path specified in your .link file.
  4. Start up Eclipse. Check Help > About to see if all your plugins and features are listed.
  5. Rinse, lather, repeat.

You can have lots of .link files and lots of install locations, which allows you to easily swap between different versions of plugins and features for testing purposes, or to share an install location between multiple Eclipse installs. And, when you upgrade Eclipse, you can just copy the old links/ folder into the new Eclipse and voom, all your old plugins and features are there. Please note that when changing between versions of Eclipse, sometimes things will end up disabled, if the new Eclipse won't work with the old plugins. If this happens, you can easily switch back to the old one, look for an update, or download a new zip.

You can also manage your plugins inside Eclipse. So, if you prefer clicking to typing, you can convert a .link file location into a Update Manager (UM) install location, so that you can use UM to install updates to plugins that you created by unpacking a zip, or just to reuse an existing folder for later UM installs. Here's how:

  1. Complete steps above. Verify all your plugins & features are properly available in Eclipse.
  2. To convert a linked folder to an "Extension Location" as used by Update Manager, you just have to put a single file in the eclipse/ folder inside the linked folder. Here's a sample:
    $ cat /home/nickb/eclipse/eclipse-plugins-europa/eclipse/.eclipseextension
    name=Eclipse Platform
  3. Remove or rename the .link file that references the folder you just converted so that you're not trying to add the same plugins twice.
  4. Start up Eclipse. Check Help > About to make sure you no longer have the plugins & features you just disabled. Then launch Help > Software Updates > Manage Configuration > Add an Extension Location to re-add those plugins & features.
  5. Restart Eclipse.


Chris Aniszczyk (zx) said...

Hey Nick, I wrote an article awhile back that discusses some of this black magic that not many people know about.

Cédric Vidal said...


Thanx a lot for this article, I didn't know about links file, and used Update Manager extension locations instead.

Links file seem a lot more convenient to manage. I'll give them a try.

Regarding UM extension locations, do you know if its possible to delete some of them ?



nickb said...


Help > Software Updates > Manage Configuration > (choose a location) > Disable

This only works if there's no cross-location dependencies (like disabling the EMF location while you have GMF installed to another location), as Eclipse won't let you break its configuration. I believe you can also force the disabling of a location by removing the .eclipseextension file and restarting Eclipse.

Anonymous said...

Note that you can use install-relative locations in the link files as well so the next time you install a new Eclipse version - at a different location - you can just move or copy the links directory from one Eclipse install to the other (provided they are siblings).

Anonymous said...

I had a requirement where I wanted one set of features while working on one project and another set of features for a second project. I did not want multiple Eclipse installations, neither did I want unnecessary plug-ins when starting Eclipse.

So I used a combination of extension locations and configuration directories to solve this.

So basically I created a hybrid install as you mentioned here and started Eclipse with one configuration and then enabled the plug-ins that I intended to use by adding the extension locations. Then, I created a different configuration for project 2.

This gives greater flexibility in terms of use of plug-ins. Any thoughts?

nickb said...

Sounds ideal. That way you can have one shared Eclipse with multiple workspaces, each one dedicated to a different purpose (CDT, PDT, JDT, PDE...).

Venu said...

I found about this links while I was evaluating Rational IDE and yes very few are aware of this.

I wrote about this some time back,

converting links to managed extension tip was useful.

Eric Rizzo said...

As rc said, you can use relative paths in the .link files, which is more conducive to sharing or checking in a target platform into source control. The trick is getting the structure and paths correct. Here are the details: