Tip: Project Level Settings

I can’t count how many times I have come across developers that aren’t using project level settings. It makes me a bit sad in the beginning, but once I show people what you can do with project level settings, I’m immediately filled with glee. Why should you use project level settings? The main reason is that you can enforce these settings all across your team (they are shareable) and even contributors to your project. Here are some examples of what I mean:

Java Settings

I recall being at a client site doing some code review… when people all the sudden started bickering about if ‘if’ statements should always be closed or not and where the ‘{’ should go. It happened that each team member had their styles that were different from what the team lead wanted. A part of me wanted to see how long the argument would go on for… but I decided instead to show them the excellent formatter options provided by JDT:

I could see the team lead’s eyes light up when he could configure these settings on a project level basis. The ability to enforce a style he wanted his team to share can save a lot of stress. Next, I told him I even had something better up my sleeves… save actions. Why have to manually format your source when you can do it when the file is ACTUALLY SAVED? I pointed him to the ‘Save Actions’ preference page:

In there, he was excited to find that you can format code on save along with organizing imports (amongst other things). However, this is only part of the story. There are a lot of other project level settings that are useful like compiler compliance settings. You can setup different projects to comply with different versions of Java depending on your needs. The point here was that you can setup a consistent level of settings to be shared by your team so when they check out the project they need to work on… they have all the settings to not conflict with the rest of their team.

Plug-in Settings

If you’re developing plug-ins, PDE provides some project level settings also. You can setup settings to flag errors if you’re missing NLS’d strings or using things like deprecated extension elements. In 3.5, you will be able to enforce versions on things like imported packages, exported packages and required bundles. Feel free to explore what you can do!

Sharing Settings

So now you’re thinking… how do I share these settings once I create them for one project? Do I have to manually craft settings via the preference pages for each project? The answer is no, however, the solution to share settings amongst projects isn’t very pretty. The easiest way to do this is to simply copy the ‘.settings’ folder over from a project that was previously setup to the new project:

This is the approach that is commonly used in some Eclipse.org projects. For example, in Equinox, the settings are available in a webpage for consumption. Be warned that you should only copy the preference files you need, you may be bringing some preferences you don’t want, so just becareful.

It’s my hope that in Eclipse 3.5, we can address some of the usability issues in sharing preferences across projects. If this issue is important to you, feel free to file a bug.

Conclusion

So what did we learn? Hopefully, that project level settings rock and there’s no excuse to not use them. There may be some usability quirks in sharing the settings with new projects, but that shouldn’t stop anyone in using something that can save you a ton of time.