Community
Participate
Working Groups
Developers working on a single project might have different preferences setup for how code formatting works. Same for organize imports, etc. This can cause some difficult merges, but that's really unimportant. A project should have a consistent format scenario (For clients reading the code). I think each Java project should be able to override the global user preferences for formatting, organizing, etc. AND, those preferences should be in the project itself, not the meta-area, so that all members of the team end up using the same prefernces. One could argue that a .java-preferences file would pollute the project, but so does .classpath, .cvsignore, .vcm... Maybe this should be addressed in core, with a .META resource folder in the project itself, where all files of this nature could be moved.
per project sharable preference settings make sense, but the basic mechanism should be provided by the Platform UI and not by JDT so that no every plugin has to reinvent sharing the mechanism. We are investigating into making some Java core options per project but we will not solve the sharability problem in JDT.
Consider as a post 2.0 enhancement
Should have been marked 'later'
Reopen to investigate
Please consider for 2.1. Some compile settings like "Non-externalized Strings" will generate 1000s of warnings if you have someone else's project loaded as source. It would be nice to turn such warning on only for your projects, not the entire workspace.
Any news from JDT team on per-project compiler settings?
Compiler settings per project are available. Select Project->Properties->Java Compiler. As Erich said, sharing these settings envolve support from the platform. Moving PR back to platform inbox since there is nothing JDT-UI can currently do.
The ".project" file has an <arguments> tag. Can JDT put their per-project compiler settings in this tag? Another issue is which settings are actually overridden in the project, and which are inherited from the workspace. Since there is no way to share the workspace compiler settings via Team environiment, how can I be sure that other team members are using exactly the same compiler settings for a given project? In other words, do you share the delta of the compiler settings, or do you share every setting, since you don't know what the workspace settings are?
I would rather edge for a separate properties file, so as to avoid mixing concerns. However, some metadata folder would be much appreciated to encapsulate these. This is currently the main reason refraining us to add support for sharing these settings. Given compiler settings are headless, the shareable project properties should come from platform/core. I think all we would need is some shareable metadata location we could use, instead of cluttering the project root folder with .files. What about a .metadata folder at the project level ? I would reassign this defect to platform/core (if I was owning it <g>).
I think the workspace vs project preference is a pretty expansive problem. For instance under preferences Java-Code Generation-Code and Comments, it is often desirable to to have different headers on top of class files since every project has different copyright notices, etc. Under Java-Code Generation-Code Formatter it seems that every project I work on has its own formatting conventions. I think some thought needs to be put into deciding which preferences would be candidates for per project modification. I was extremely happy when I saw the Java-Compiler settings were made available on a per project basis and would love to see some of these other settings made available also. Thanks for the great work!
The Java compiler settings are now available on a per-project basis as well as being shareable in a repository. Other plug-in developers (e.g. PDE compiler, etc) are being encouraged to convert their preferences to be available on a per-project basis. If there are certain preferences which you wish to be per-project, please open a bug report against the team owning those preferences.
Which build is this avialable? What is the bugzilla which tracks the change you are talking about?
Per-project shareable compiler settings were made available in Eclipe 3.0. Encoding settings as well. Per-project shareable PDE compiler settings were released to Eclipse 3.1 M3. (bug 77042)
Erratum: compiler shareable settings were made available in 3.1M1, see bug 59258
bug 59258 should have been a dupe. Sharing code formatting settings has not been addressed. Compiler settings are moved into a ".settings" folder without telling the user that this is happening. This might be confusing.
Actually, I can't set formatting setting per project at all.
Old Summary: [Preferences] Some java preferences should be like .classpath, project scope and 'teamable' Philippe, is there already a bug report for per-project formatter settings? I looked quickly but didn't see anything.
I think I see a potential problem. A set of projects should share the same formatting or compiler settings. Currently, there is a complete copy of the compiler settings in every project. This means if I make a change in one place, it is not propagated. Maybe a project should be able to inherit another project's compiler settings if present. In which case it's preference page would be disabled with a link to edit the base project's settings. Same for formatting of course.
The problem is how to present this to the user. The infrastructure is there, (even to inherit from the workspace level at a per-setting basis) but how do you display that to the user in a simple manner?
Just another radio button I guess. And then a drop-down combo which get's enabled and presents existing (or maybe just project on which the given project depends)
To make the problem more complex, you can have per-project, per-workspace, and per-configuration settings. The framework also allows plug-in developers to create their own "project scopes" so the question is how to show these to the user as well? The list goes on and on. Anyway, discussions about the presentation of the preference scopes to the user in the UI should be discussed in Bug 71124. We'll leave this report for the enhancement of having per-project shareable formatter settings.
per-workspace and per-config settings are not committed to CVS. Since compiler preferences are now dumped into CVS by default, it only makes sense to allow users access to settings which live in CVS, no?
*** Bug 84534 has been marked as a duplicate of this bug. ***
(In reply to comment #20) > The problem is how to present this to the user. The infrastructure is there, > (even to inherit from the workspace level at a per-setting basis) but how do you > display that to the user in a simple manner? Why not add a mirror of the entire preferences hierarchy under each project, named Project Preferences. The default would be to use workspace settings, with a UI exactly as the java compiler settings are now. So the two buttons on top (Use workspace settings/Use project settings) and the tab to configure workspace settings. Underneath would be whatever was normally in the corresponding workspace preferences region. Seems like you're headed in the right direction UI wise. I'm not familiar with your codebase, so I can't state specific suggestions on code/plugin implementation.
Moving to UI for further analysis
Per project formatter settings are available in 3.1. If someone disagrees with the current solution please open a separate bug report.
