All the members of my team works with Eclipse. However, each one have different configuration, preferences and plugins. What is the best way to keep a baseline of plugins, preferences such as code styling and formatting, and other configuration in order to have similar start point but to allow each team member for specific configuration.
I am looking for a solution that will be easy to maintain also, means not too many files that resides in different locations.
A simple approach for preferences is to use File>Import and File>Export, choosing General>Preferences, then the preferences you want to share. For a few of my past teams, we stored the baseline preferences in version control.
You should check out Pulse. I've only used it in a standalone, single user environment, but it seems to work pretty well. I believe with the paid versions you can manage workspace preferences and settings across your group. I may try and get my company to try this out soon.
Basically, Pulse provides a central launchpad for Eclipse. It allows you to create Eclipse install profiles that consist of an Eclipse install and various plugins. From the launchpad, you select a profile and install it. This downloads Eclipse and the various plugins to a central folder on your machine. It then sets up a profile folder that somehow links the specified plugins for the profile. So when you launch, you only get the items in the profile regardless of what other profiles have installed.
We use a "baseline" approach where we have a central version managed by a few core members. The idea is to get the version downloaded, configured as you wish and then the workspace AND install packaged to the central location. Additionally, some plugins have config files that we store in a central location and we then point the baseline them (templates, formatter files, etc).
There is also commercial software that will do all this for you, if I can find it I'll post the link.
Hope this helps.
I found a solution in another question on the site.
It recommends a plugin called workspace mechanic. Looks like it solves the preferences and configuration issues.
I am using it and it looks good for configuration. it doesn't give a solution for plugins though.
I asked a similar question and was recommended Yoxos. Havent had time to try it yet, but it looks promising.
The most important part is the plugins that you are working on, I suppose. What we do is to put the source for all the plugins that are subject to development into revision control, then import the projects into a fresh Eclipse workspace without copying them. This is probably obvious.
A little trickier is the plugins that are part of the runtime environment. We have a special project (also under revision control) that contains those jars, organized in directories. Some are from Eclipse, some are from Spring, logging stuff etc. There also is a target definition file, that defines which of these plugins make up the environment. So you are not compiling and running against the Eclipse copy that you are developing in, but an independent set of plugins that is defined as the target platform.
Understanding and using a target platform makes a big difference, as it doesn't matter anymore what exact version of the IDE you are using - all developers will link against and test the same code. A nice side-effect is that you control the subset of plugins that are part of your product, and it is impossible to accidentally pull in 17 new plugins through an innocent new dependency.
PDE/Build unfortunately doesn't know about target definitions, but the file format is easy enough to figure out.
Finally, preferences and formatting etc can be exported to a file and stuck in revision control, if it matters. Standard formatting rules are useful, I guess.
