Workspace settings vs project settings

Today, I wanted to talk about the evilness of workspace settings. Workspace settings are used for a project when the project doesn't specify its own settings.
There are really good reasons why workspace settings should never be used for a Java project and in particular for a Plug-in project. To specify project specific settings, just open the project Properties, the select the options you want to be specific to your project and select "Enable project specific settings". For example, for compiler settings, it would look like this:

Let's take a Plug-in project that is using a EE (Execution Environment) 1.4 and therefore it doesn't use generics. Now you don't set project specific settings for this project, which means that once this project is checked out inside your workspace it will be compiled using the workspace settings. If you are using a 1.6 VM to run your workspace, the default compiler settings for this workspace will be set to 1.6.
So your project might end up with many warnings once checked out that are unexpected: raw type warnings, unchecked type warnings,...
When you set up a Plug-in project, you should also set up all compiler settings to be specific to this project. You should set the libraries on the classpath to explicitly point to your EE.
You must make sure that compiler warnings are set up so that your project compiles without any warnings or at least a limited number of warnings. Warnings should always be under control. You either don't care about some warnings and in this case they should be disabled, or you do care about them and then they should be fixed.
Setting project specific settings means that any user that checks out your project will get consistent compilation regardless the workspace settings they are using.
This also means that any Plug-in project should always set an EE. Without any EE explicilty specified, the default VM libraries are set up on the project's classpath and this means that the classpath depends on the workspace settings.
This being said, if you do set an EE for your project, you should also make sure it is using API tooling even if you don't really provide APIs in your project.
You can at least benefit from the detection of invalid references to the EE you are using. API tooling has a disabled option (by default) that you should enable for your project to detect all invalid usage of types, fields and methods that are not defined for the EE specified for the project. See Project's Properties>Plug-in Development>API Errors/Warnings>API Use>General>Invalid references to system libraries.

If you follow these guidelines, you will definitely help any users of your project that want to check out the code in their workspace. The compilation of your project becomes predictable and repeatable in any workspace. No more "I don't understand why my project doesn't compile when I checked it out from CVS....".

Hope this help you to setup your new projects or adjust the settings of your existing projects.