How does one automate configuration of Eclipse?

Question

A team working on a project will tend to need a common configuration of Eclipse. This includes general configuration and project specific configuration. For example, generally, everyone might wish to share indentation, installation of certain plugins (say m2eclipse, testng, egit, Spring support). Further, for a project, you might want specific plug-in configurations (e.g., for m2eclipse, setting up a custom Maven settings file, configuring extra Maven targets for eclipse build events), or a custom Eclipse target platform, or even just to set-up certain custom launchers.

Currently, my team executes a series of manual steps to try and get everything configured correctly. This is tedious, error-prone and difficult for new developers to follow. Instructions also tend to get out-dated.

To what extent can this sort of configuration be automated? How should it be done?

Serafinaserafine

Answer 1

The simplest thing available without modifications is to have a common preferences file (Export->General->Preferences), which everybody can then load. Works the best with the same Java installations present.

It is possible to drop in plugins these days but I have not worked with it. Also it might be beneficial to create a local repository with a default package depending on all the plugins you want. Then you can just install that and it will pull in the references. A local cache might be very beneficial as some repositories are quite slow.

Drosophila

Is there a way to script the deployment of preferences and plugins? I'd much rather have people run some sort of shell script or batch file than have to click multiple things in Eclipse. – Serafinaserafine

I have asked the same thing, and there was no simple cure except to zip up workspaces and eclipse-folder. I dislike that too. – Magnetism

Answer 2

There are several solutions for sharing Eclipse Installation/Configuration and settings. For example, Pulse (has a free version). If you browse previous questions in StackOverflow, you will find many discussions regarding these issues.

I would suggest against copying the configuration and workspace folders. From my experience, it won't always work. Plus, this technique only works once. It doesn't sync later.

Update: I just recalled that there's another useful plugin to checkout: Google Workspace Mechanic.

Surovy

Pulse allows syncing workspace settings and preferences as well as plugins. You might need the paid edition to do it in your team. – Surovy

Answer 3

configure the eclipse at one workstation and then make a zip file or rar file for the same and pass it to others.. that will help and otherwise you can also write cmd scripts to copy the plugins and other useful stuff in to the same and these will be less error prone.

Pyro

@Emil sorry that was rar file not war file. – Pyro

And document the steps that you took to configure the master copy for those who want to roll on their own – Medicinal

Answer 4

i agree with "Thorbjørn Ravn Andersen" but the preferences export doesn't export all preferences, especially from additonal plugins. you should additionally als zip a working eclipse and provide it to all teammembers.

Drosophila

Answer 5

Configure it once and then make copies of the configuration folder. If its not enough, copy the entire Eclipse folder.

Haase

How can you ensure that there aren't localized paths etc in the configuration folder or eclipse folder? If adding plugins like testng, don't they put stuff in the plugins folder? – Serafinaserafine

Answer 6

I think different parts have different ways to configure/share.

1. installation

   The installation could be installed in the nfs as central deployment, and maintain by administrator. All team members share the installation(eclipse and other plug-ins).

2. plug-ins preference

   The preferences of some feature could be exported a file, then imported in other environments. But it depends on the implementation of the plug-ins. For example, you can export/import key setting and jre setting.

3. project's specific settings

   For example, the java compiler level and code format setting are stored .pref configuration file under the folder of project. You can manage them via source control tool. So those setting can share among team members.

Edward