Eclipse: How to share Java compiler errors/warnings settings across entire team

Question

We are in the process of standardizing our default Eclipse configuration (styles, settings, dictionary, formatting, run configurations, etc.) for our developers.

However, for Java compiler errors and warnings preferences, there does not seem to be any way to export/import settings. Is there another way to do this?

Answer 1

Eclipse allow you to export your preferences via

File > Export > Preferences

You will see a list of exportable preferences, which contains Java Compiler Preference , you can even choose specified preference to export.

After that, you can import the preferences into a new workspace via

File > Import > Preferences

Answer 2

The ideal way to share settings within the team (for use within the IDE) is to use project specific settings . The project specific settings become part of the project and go into source control repository, hence every team member gets them for free.

Most of the settings you mention in the question can be configured per project.

Answer 3

I've developed a maven plugin (called codecleaner) that spread pre-configured eclipse settings for maven projects. It is very usefull wehn you dont want to put eclipse settings under version control, or when you want to save the time for manulay add the settings for each of the projects

https://github.com/yonatanm/codecleaner

currently The codecleaner plugin update the following types of eclipse settings:

• Code Formatter
• Save Actions
• Clean up settings
• Compiler Error/Warning level
• JSP/XML/XSD/HTML Validation

Answer 4

In our team we use workspace mechanic to share the same workspace preferences by putting the preferences files on a shared drive. A small introduction can be read here .

Answer 5

Create a common build file (using Ant/Maven). If you use Maven, you can even ensure that the same jars are used by everyone while compiling.

Answer 6

This can be fixed outside of Eclipse, starting with standardizing the build process as Amit mentioned.

You might also want to consider a continuous integration system which builds every time someone commits code. This keeps everybody on their toes, preventing people from pushing broken code. Any compiler errors/warnings are visible to everyone.