We’ve got several developers (more than 5) at work using Eclipse, and some are pretty new at it. We gave each a list of the plugins that we’d like them to install, and some that are optional. Some people put them on, and some didn’t have time to read through and understand how to install them all in addition to understanding what they’re for and how to use them. To make that easier, we wanted to install all the plugins at once for them, and also make it a really simple to upgrade the main Eclipse installation.
We took a tip from the MyEclipse folks (no, we don’t use it), and setup a few directories as Externally Linked Features or Product Extension. So we setup a few directories like this on a shared drive:
stable-plugins/ eclipse/ features/ first.feature_1.0.0/ next.feature_1.0.0/ plugins/ first.feature_1.0.0/ next.feature_1.0.0/ first.plugin_1.0.0/ unstable-plugins/ eclipse/ features/ trial.feature_1.0.0/ plugins/ trial.feature_1.0.0/
And then on each developer’s machine, we create a place for them to put their own individual plugins.
user-plugins/ eclipse/ features/ plugins/ user.plugin_1.0.0/
Finally, there’s just a few files and one directory to create in the main Eclipse installation on the developer’s machine.
eclipse/ [...] links/ stable.link unstable.link user.link [...]
.link file contains the path to the directory above. For example, the
stable.link file looks like this:
Notice that it’s the path to the
stable-plugins directory, and not to
stable/eclipse. Eclipse expects to find the
eclipse directory under the
path pointed to in each
When we go to install a new plugin, we just make sure to choose which installation the plugin should go under. Remember that if you’re installing more than one plugin at a time, each one requires you to select the installation directory individually.
Select the plugin location for the first plugin…
…but the second plugin location has to be selected as well.
We can allow developers the freedom to disable any of the provided plugins, or even disable all the plugins for a particular extension location (like
unstable-plugins). Simply go to
Help > Software Updates > Manage Configuration. Click on the extension location, and then click
Disable on the right.
We need to do one more thing before we can have a seamless upgrade of Eclipse from one version to the next: the workspace must not be in the Eclipse directory. We’ve setup our code similar to this:
work\ company-repository\ .metadata\ project1\ project2\ other-code\ .metadata\ oss-project\
We choose a standard place for the workspace to exist. Our source code repository ignores the
.metadata directory, and all of our projects are located directly under the chosen workspace (
C:\work\company-repository). This makes importing projects into the workspace easy, it keeps all of our code together, and it allows us to have a separate workspace for other code, such as open source software.
Now we’ve got a really great Eclipse configuration. We can share plugins amongst all of our developers in a standard way that ensures everyone has the right versions and such. Developers can choose to ignore unstable plugins, and they can add any plugins of their own. On top of that, there’s only one directory added to the standard Eclipse installation directory — the
links directory. That means that it’s easy to upgrade to 3.1 or any milestone build. All you need to do is drop the
links directory into the new installation, and you’re ready to go. When you open your new version of Eclipse, you’ll simply choose your existing workspace and all of your projects will appear, and your plugins will be installed (assuming they work with the new version).
Anyone who tried to keep up with the moving milestones of 3.0 can appreciate how easy this configuration is to upgrade frequently, and if you’re looking for a way to standardize the Eclipse plugins used in a corporate environment this just might work for you. If you’ve got improvements to this setup, I’d really love to hear them!