Tip: Project Level Settings

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:

formatter-control

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:

save-actions

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!

pde-settings

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:

settings

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.

6 Comments
  • Posted at 08:59, 2008-09-09

    For those who want to the feature request mentioned in the post, here is the bug in question:

    https://bugs.eclipse.org/bugs/show_bug.cgi?id=246755

  • Posted at 09:01, 2008-09-09

    Chris, ask and ye shall receive. 😛

  • Posted at 10:23, 2008-09-09

    What would be a cool, is an easier way to say apply these workspace settings to all workspace projects, this obviously would have a caveat of duplication of settings.

  • Posted at 02:41, 2008-09-10

    I’ve seen so many people actually deleting the .settings folder in their projects (“What’s this? I didn’t create it”) before checking in, it always make me want to cry… Good to have people like you who spread the word that project level settings are a Good Thing ™!

  • Bill Trautman
    Posted at 19:14, 2008-10-02

    Guys I have seen issues with project level settings for some things where the settings captured developer workstation instance information that is not common. once checked in as part of project there is always the issue that I either need to reconfigure my machine to match those of the commitor or i need to throw away/adjust settings. Other option is to check in my settings. which starts its own war. Thoughts one how to avoid this?

  • Posted at 08:51, 2008-10-03

    @Bill, do you know what type of settings these are? Most of the project-level settings shouldn’t be machine specific. I’m willing to help, but I need some more details to see what’s going on. Feel free to email me.