Eclipse’s big strength is its plugins – they make it easy to add new features to the IDE. But plugins can make life difficult when you have to reinstall Eclipse (eg. moving up a version) or have multiple installations (eg. for C++, Java and PHP). Because plugins are normally installed in the plugins folder underneath your Eclipse installation, they aren’t shared by other installations
You could always install the plugins again and again for each installation. That would mean for Subclipse (or favourite), your favourite XML editor, UML tool, etc. This is extremely slow and frustrating.
There is a feature that makes life easier though. You can copy plugins to an external folder and create shortcuts to them via link files. Then you can copy these link files to any Eclipse installation.
How to set up link files to share plugins
To see how to use link files, I’ll add the popular code checker Checkstyle to Eclipse. I’ll be using a technique shared in this post (by Michael Scharf) to make things work smoothly with p2, Eclipse’s new provisioning system.
1. First, download the plugins (Checkstyle download), preferably in zip format for local install (ie. not via an Eclipse update site).
2. Create a folder where you’ll be storing all your plugins. I use C:\eclipse-plugins for all my plugins but you can place them anywhere and even in totally different locations.
3. Extract the Checkstyle zip under the folder c:\eclipse-plugins\Checkstyle\eclipse (notice the eclipse folder underneath Checkstyle’s folder).
If you’re unsure about how to create the folder structure, have a look at this video:
4. Create a file called .eclipseextension (note the dot in front) in the folder c:\eclipse-plugins\Checkstyle\eclipse, with the following content:
| id=org.eclipse.platform name=Eclipse Platform version=3.3.0 |
(Alternatively, download the file, rename it to .eclipseextension and copy it into the same folder).
NB! This step is only necessary since Eclipse 3.6 (Helios), but will work on previous versions as well and should make sure you’re covered in case you upgrade to 3.6 – (thanks Rab).
5. Start up Eclipse with the following command line to initialise all the p2 stuff in the external folder. You only have to do this once:
eclipse -configuration c:\eclipse-plugins\Checkstyle\eclipse\configuration
6. Go to your Eclipse installation folder and add a folder called links. In this folder, create a link file named Checkstyle.link (with your favourite text editor) with the following content (NB! Notice the front slashes, even in Windows):
path=c:/eclipse-plugins/Checkstyle
If you’re unsure about how to create the link file, have a look at this video:
7. Restart Eclipse normally (without the command line args) and you’re done. You should see your new plugin’s functionality, in our case the Checkstyle views should appear on the Show View menu. If you don’t, see the troubleshooting section below.
8. Now you can copy this links folder over to as many Eclipse installations as you want. You have to create one file per tool/extension, so if you’re installing Subclipse, there should be a Subclipse.link in the links folder pointing to Subclipse’s plugins.
Notes:
- Eclipse expects plugins to be in the plugins folder and features in the features folder of the external location.
- If you’re dealing with a tool that doesn’t have plugins or features folders (eg. XMLBuddy has only one plugin folder) then be sure to create a plugins folder below the eclipse folder and drop the plugin in there.
So how do you share the plugins between installations or reinstall using links?
Simple. Once you’ve got the links folder set up in one installation, copy it to the other Eclipse installs you have. You only have the plugins defined once (under c:\eclipse-plugins) and the link files are basically shortcuts (or symbolic links) to these plugins.
Reinstalling is easy as you only have to either recreate the links folder and files in the new installation or just restore a copy of the links folder you had before from a backup.
Once you’ve copied the links folder, Eclipse should pick up the plugins when you start it. If it doesn’t, see the troubleshooting section below.
Troubleshooting – It’s not working
Here are some common reasons why it may not be working:
- You didn’t create a folder called eclipse between the plugin’s name and the features and plugins folders. For example, we copied the Checkstyle zip’s content to the folder c:\eclipse-plugins\Checkstyle\eclipse.
- You should use front slashes instead of backslashes in your link file.
- The link filename must end with the .link extension. Eclipse doesn’t recognise any other file type.
- You might not have initialised the p2 stuff. Remember to run eclipse the first time with the -configuration argument.
- If you’re using Eclipse 3.6, you might have skipped the step where you need to copy over the .eclipseextension file.
- If it’s still not working, you might have a dependency problem, version problem or something else wrong with your plugin. See the Error Log view (Alt+Shift+Q, L) in Eclipse to see if there are any errors.
But what about p2? Aren’t links going out?
Not really. p2 (Eclipse 3.5’s new provisioning system) has introduced a new way of adding external locations, but it does still support the old-style links.
In p2, you can also put your link files in the dropins folder without needing to create a links folder. However, remember that the dropins folder can also contain other plugin jars and folders.
My recommendation? I still prefer old-style links folder because (a) it only contain the link files so is a lot cleaner and (b) it’s easier to copy because it only contain link files.
There is a small caveat, though, but really small
There is a small caveat to using link files, but it’s really inconsequential compared to the benefits you gain by being able to share plugins: To use the update manager to update plugins the external location, you have to start Eclipse again with the -configuration argument and give the path to the tool. Then you can use update manager as normal, update the plugins and run Eclipse again as normal.
Not really a problem, but just something to keep in mind.
Related Tips
Here are some other things you can do to make your installation and setup easier:
- Checkout multiple projects automatically into your Eclipse workspace with Team Project Sets
- Share Eclipse perspective layouts across multiple workspaces
- Use Fast Views to maximise screen space
- Automatically format and cleanup code every time you save
- Categorise projects in the Package Explorer to reduce clutter in Eclipse
Hi, great site – thank for all the tips.
Similar to this, you can launch various workspaces using additional shortcut parameters. Why would you want to setup multiple Eclipse installations over multiple workspaces?
Thanks John – much appreciated.
Yes, you’re right that you can launch multiple workspaces using the same version of Eclipse, but this isn’t aimed at multiple workspaces, more at managing multiple installations.
Here are some scenarios where this would be useful:
* If you upgrade your version of Eclipse (eg. 3.4 to 3.5), you can use this to setup your new installation. You wouldn’t want to go through the hassle of installing all the plugins again.
* Sometimes you want to use different variations of the same version of Eclipse, eg. JEE, PDE or just JDT, depending on what project you’re working on. This comes in handy for those situations.
* I sometimes do C++ and PHP development, so would use Eclipse CDT or PDT. As there are plugins that are common across any Eclipse IDE (eg. Subclipse, EditorList), I’d often share these amongst the installations.
* If you’ve customised your Eclipse installation at work with a number of plugins, you may want to use the same plugins at home at some point (or vice versa). This allows you to just copy the same plugins over without having to install them again. Of course, this counts anytime you want to share a setup between any two machines, eg. your desktop and laptop.
In all situations above you’d normally have to use the Update Manager to install all your plugins again. Using link files avoids this, meaning all plugins are availabe immediately.
Thanks for these examples, Scenario #2 is a big one, especially with those specialized packages like PDT, Android, CDT, etc. Makes alot more sense that way!
Your doc is very useful and much appreciated . This worked OK for galileo – I could see that Eclipse detected my subversive plugins (using About Eclipse SDK–>Installation Details–>Plugins) but helios(released after your doc was written) does not seem to retain the same plugin detection method -the same operations could not detect the plugins.
Rab, you’re right, the tip works for 3.5 (Galileo) and below. I’ll do some research on Helios to see what’s changed and what’s the new procedure.
I’m not on Helios yet so will try to make some time to check it out, but I’ll update the tip once I’ve figured it out.
Hi Byron,
I did it. But it doesn’t work for me.
I’m using Eclipse 3.6 Helios.
MSV, please see the reply to rab. I’ll update the post once I’ve figured out what the procedure for Helios is.
Hi Byron, It worked. Because file must be save with ANSI encoding, UTF-8 encoding not work.
Thanks so much.
I may have some corrections to the points I mentioned, as I try to discover a bit more. Will try to post an updated version soon, to replace the older one.
Thanks rab, I’ll wait for your corrections before posting your follow-up comment. Thanks for the effort – it may help someone else out in the meantime.
Confirming that Byron’s post of installing plugins manually by copying zip contents to the features and plugins also holds for eclipse helios(3.6) after my experimentations.
With just a lean SDK install of helios I had the plan to make all my plugins reside outside that installation directory at some $SHARED_PLUGIN_HOME . Note each plugin under $SHARED_PLUGIN_HOME at $SHARED_PLUGIN_HOME$PLUGIN_NAME has a directory structure specified below. The key is that, once this plugins were installed by a manual unzip or from inside Eclipse through update manager, I needed a .eclipseextension file in each $SHARED_PLUGIN_HOME$PLUGIN_NAME to work, where a .eclipseextension file is as follows (thanks to http://divby0.blogspot.com/2007/06/managing-plugins-and-features-with-link.html )
id=org.eclipse.platform
name=Eclipse Platform
version=3.3.0
Select All files when you save this file in notepad – otherwise windows wont let you save a file beginning with a .).
here’s the plugin directory structure
$SHARED_PLUGIN_HOME
— $PLUGIN_NAME
—- eclipse
—— features
—— plugins
—— configuration
—— p2
—— artifacts.xml
—— .eclipseextension
Also confirming that plugins installed by Eclipse’s update manger are also recognized at eclipse restart, again, if I have that .eclipseextension file. Remember the discipline needed to be followed every time you plan to install a plugin. You need to start eclipse –configuration $SHARED_PLUGIN_HOME$PLUGIN_NAMEeclipseconfiguration as in Byron’s doc. This tells the Eclipse update manager that it needs to install the plugin/feature at $SHARED_PLUGIN_HOME$PLUGIN_NAME which in turn creates the p2, configuration subdirectories within the plugin directory.
Nice work, Rab, thanks for this. I’ve updated the post with the extra step to create the .eclipseextension file.
I’ve tested some plugins and they consistently work with the .eclipseextension file. The funny thing is that some require the file (eg. Checkstyle) but others don’t (eg. Subclipse). All work with the file, so it makes sense to create it consistently.
BTW, I’ve added dashes in your comment to illustrate the folder structure (seems like WP strips out the spaces).
Thanks again for all the effort and for publishing the solution.
Two things:
(a) the plugin directory structure indentations somehow wiped out from my post. That structure is $SHARED_PLUGIN_HOME$PLUGIN_NAMEeclipse and under it the rest
(b) Question: In another similar post at http://www.venukb.com/2006/08/20/install-eclipse-plugins-the-easy-way/, Roman Porontikov in that page seem to imply that the eclipse extensions versus .link approaches are independent – dont know how true is that or if I am missing something because at least for helios on the contrary it seems that these are co-dependent. So if someone gets this stuff to work without the .eclipseextension file and/or have an explanation why this works with respect to any changes in helios, please let us know.
As explained in
http://wiki.eclipse.org/Equinox_p2_Getting_Started#Links_Folder
this functionality is now implemented by dropins.
You’re right, Marcello. p2 does support this functionality in another way, specifically bundle pooling together with the dropins folders. The reason why I haven’t used bundle pooling is that there is very little information on how to actually use it properly and at the time I wrote the tip, p2 had just come out and was still… maturing, whereas extension locations had been around for a very long time. (Also, link folders work for 3.3 and lower as well, whereas p2 came out with 3.4)
If you have a good link that describes how to use bundle pooling to share plugins, then please let me know. It would be nice to have different options for sharing plugins.
Pingback: More shortcuts/quickfixes for eclipse « Bkiew's Blog
Thanks for this great and useful post.
This mechanism is working on my Windows XP box with Eclipse Helios, but not working on Fedora 13 with Eclipse indigo.
Please suggest.
Thanks.
Thanks rits, glad I could help.
Try out some of these and let me know if it works. Since it’s working for you on Windows, I’m focusing on the things that apply specifically to Linux:
1) Make sure you’re using the absolute path to the plugin directory in the link file and not the relative path, eg. instead of path=~/eclipse/plugins, use path=/home/username/eclipse/plugins.
2) Ensure that the user you’re running Eclipse with has enough permissions to the directory and subdirectories where the plugins are installed. I once made the mistake of installing the plugins with one user but running Eclipse with another that didn’t have sufficient permissions.
3) Also check permissions to the .eclipseextension and link files.
4) Lastly, make sure the directory names in the link file match the directory path exactly as it’s case sensitive.
Let me know if any of these helped. If it still doesn’t work, please have a look at the Error Log view (Alt+Shift+Q, L) in Eclipse and let me know if there are any errors that show up there to do with the plugin you’re trying to install.
I have tested this on Eclipse indigo – works perfectly on mac os x lion.
I followed the same process of this doc to install the eclipse plugin for clojure(http://code.google.com/p/counterclockwise/) but I could see no icon in the perspective like other plugins. This led me to think initially that something’s missing. But then on the package explorer pane, when I right clicked New–>Other – I saw that the plugin was indeed installed (on indigo, os – mac osx lion) – as it offered me the option to open a clojure project – on opening the plugin features (e.g. colored parentheses) were indeed working ok on the new file. This leads me to think, that eclipse plugins themselves might possibly be built in a minimalistic way that allows the plugin to exist in eclipse, without announcing its presence in the perspective pane. So before anyone concludes that the plugin isn’t installed this way – make sure to check the New–>Other option on right-clicking the package explorer pane – you may find that the plugin has been installed!
Thanks for the update, rab, glad it’s still working for you. Yes, I normally go to Help > About Eclipse > Installation Details to make sure that the plugin’s actually installed if I don’t see the plugin’s expected features. It sometimes came down to me looking in the wrong place.
Update for Eclipse Luna(4.4.1)
– checkstyle plugin still worked this way.
– findbugs plugin doesn’t. got it work only by copying the unzipped folder to the plugins folder of eclipse home(as instructed). Note the findbugs plugin does not come(any more?) in two folder format( features, plugins).
Thanks for the update, Rab. Re Findbugs, it might work this way if you follow the same instructions (ie. start Eclipse pointing to the findbugs configuration folder) but then go through the normal installation process (Help > Install New Software) instead of copying the zip over.
I haven’t tested it myself but I have found that to work for other plugins if the manual process doesn’t work. However, I have seen it not work for some plugins, eg. the Antlr plugin, but it normally does work.