Managing Eclipse Preferences for Teams (EclipseCon 2011)

Editor's Notes

• #2: \n
• #3: \n
• #4: \n
• #5: In a team and even among multiple workspaces, one tends to have very different preferences. Basically, that's perfectly fine and in most cases the users may configure Eclipse to their liking. However, there are a number of settings that need to be coordinated to make sure the project doesn't run into technical troubles and inconsistencies. Examples for that type of preferences are:\n - file encoding\n - SCM settings like (content types, auto properties, ...)\n - compiler options (same code might behave differently on different machines)\n - …\n\nSettings that adapt/hook up Eclipse to the local development environment are best coordinated for efficiency. Examples for that group of preferences are:\n - SCM repositories\n - Mylyn task repositories\n - file templates\n - update sites\n - …\n
• #6: In a team and even among multiple workspaces, one tends to have very different preferences. Basically, that's perfectly fine and in most cases the users may configure Eclipse to their liking. However, there are a number of settings that need to be coordinated to make sure the project doesn't run into technical troubles and inconsistencies. Examples for that type of preferences are:\n - file encoding\n - SCM settings like (content types, auto properties, ...)\n - compiler options (same code might behave differently on different machines)\n - …\n\nSettings that adapt/hook up Eclipse to the local development environment are best coordinated for efficiency. Examples for that group of preferences are:\n - SCM repositories\n - Mylyn task repositories\n - file templates\n - update sites\n - …\n
• #7: There is not a single configuration file for Eclipse and the configuration is spread over several files and scopes. There are even several different mechanisms and APIs for different types of configuration and in some cases configuration on one place overrides the same configuration in another place (e.g. workspace vs project level; command line arguments vc eclipse.ini). The most common places where Eclipse can be configured in some way are:\n- eclipse.ini: system properties, JVM options and program arguments\n- preference store: the majority of preferences is stored here. This is a workspace level store.\n- secure store: store for passwords and other sensitive information. If install directory is writable, it is stored in the eclipse directory\n- some extensions have their own mechanisms\n\n
• #8: Put as much as possible on the project level:\n- configuration is managed in the SCM\n- updates are distributed to developers as normal SCM updates\n- different projects may have different configurations (java version, different license headers, different coding styles for different customers) and still be checked out in the same workspace\n- different project types may have different configurations\n- tools run during the continuous/release build can be configured to use the same config (e.g. FindBugs, Checkstyle, PMD)\n\nDisadvantages of putting preferences into the project:\n- Changes in multi module projects must be replicated to the projects (If you use Maven, the Maven eclipse plugin can help here)\n- Some developers complain about the number of .-files in the projects\n\n
• #9: I am sure you know at least one project having one of these famous "How to set up the devenv" wiki pages or readme files.\n\nOne one hand, they solve the problem of preference synchronization. On the other hand they are broken for some reasons:\n- People don't know where the document is\n- Going though an endless checklist is a mundane task and people tend to do errors in boring tasks\n- Keeping this document up-to-date is a pain\n- Delta-checklists are needed if there are changes\n
• #10: Eclipse offers a preference import / export mechanism that stored all preferences from the preference store in a so called Eclipse Preference File (EPF).\n\nProviding a common EPF file on a shared file system simplifies the configuration for the users compared to the checklist. The problems about this solution are:\n- people don't know where the file is\n- the import must be done manually\n- after changes, the developers need to re-import the file\n- on each import, the user needs to know the location of the file\n
• #11: Eclipse Team Etceteras is a set of small enhancements to existing Eclipse preference functionality that ease the use:\n- import EPF files over HTTP\n- preconfigure the EPF URLs so that the users don't need to find the file\n- remind developers when they create a new workspace to apply the default configuration\n- Ad-hoc EPF import over HTTP (paste URL into import wizard)\n- transfer preferences from one workspace to another\n\n\nCredo: Help the user but don't get into the way.\n\nDisadvantages:\n- limited to what EPFs can do\n- no enforcement capabilities\n- pre-configuration is done using a fragment bundle: need to deploy an own configuration plug-in along with Eclipse\n
• #12: Workspace Mechanic is a very powerful task oriented tool to administer Eclipse configurations. A task can be a Java class, a Groovy script, a Plug-in or an EPF file. Importing EPF files is just one of many possible tasks. You can extend Workspace Mechanic by providing new task and new task types using extension points. Tasks are picked up from shared file system locations by Workspace Mechanic in a configurable frequency. If anything needs to be done, the user is prompted to apply a so called 'Fix' in a notification. \n\nWorkspace Mechanic offers some nice tools that make the lives of the administrators easier: creating a EPF file for a task is very simple thanks to the preference recorder.\n\nDisadvantages:\n- no enforcements\n- a shared file system is required (as of now), HTTP capability is committed but not yet released\n- pre-configuration is done in plugin_customization.ini or an EPF file: need to deploy that file along with Eclipse or being imported\n
• #13: In Bug 334016 Ericsson donated a preference management tool. As there seems to be no official name, it is referred to under it's Bugzilla ID. At the time of the writing of these slides it was unclear whether, when and how the contribution will be included into Eclipse (according to C. Aniszczyk). There is no update site to install this functionality from - interested users need to get the source out of the attachments of this bug and build/release the plug-in themselves.\n\nThe features offered:\n- import EPFs over HTTP\n- lock-down of preferences\n- automatic imports upon workspace startup (enforcement)\n\nDisadvantages:\n- not easily available from an update site or Eclipse Market Place\n- limited to what EPFs can do\n
• #14: \n
• #15: \n
• #16: Demo of Eclipse Team Etceteras:\n\n1. Start Eclipse with new workspace\n--> ETE new workspace detection and preference import\n\n2. Change workspace name (General > Workspace > Name)\n\n3. File > Switch Workspace… (to a new workspace including preferences transfer)\n--> in new workspace: show transferred preference (workspace name)\n
• #17: Some plug in do not make use of the preference store to keep their configuration. Examples are the XML catalog and Mylyn. The “self made” storage is rather problematic for people in charge of providing a consistent configuration among a team. If you are a plug-in developer, please make use of the preference store whenever possible. In case you can’t, please provide: \n- stable import/export API\n- a configuration possibility using extension points, fragments, …\n- a transfer implementation to transfer the configuration between workspaces.\n
• #18: \n
• #19: \n