Community
Participate
Working Groups
My workspace has 400+ projects in it, of which approximately 80 are "owned" by the group I'm a part of. We want to be able to set the JDT compiler preferences (i.e. what's a warning and what's an error) on the 80 projects we own, but not on the other projects. It gets pretty tedious editing the project preferences on 80 projects. We'd like to be able to either: * select N (i.e. multiple) projects from the Preferences > Java > Compiler > Errors/Warnings > Configure Project Specific Preferences... dialog, such that we're effectively editing N preferences files at once * specify that N - 1 of our projects reference/inherit the preferences of 1 of our projects (it would be nice if a project could inherit preferences, and selectively override a subset)
It would be great if preferences could inherit from other projects. This is however, in the current state a breaking change. So what we can do is to - offer compiler setting profiles - offer functionality to copy settings to one or more other projects.
This is not JDT specific.
I agree this is a problem. The best workaround I know is to copy settings at the file level as opposed to going through the UI. For example, compiler settings are in <project>/.settings/org.eclipse.jdt.core.prefs
*** Bug 246755 has been marked as a duplicate of this bug. ***
It's interesting that the summary of this bug is "Set (or share) preferences" since multi-setting is actually VERY different than sharing. Multi-setting Preferences is possible as a UI enhancement without changing the underlying functionality. An infrastructure for "sharing" Preferences must be at the Core level before UI can adopt it. If done well, however, it's much more powerful: settings could be "shared" not only from a team-shared location, but also from a location that's shared across multiple workspaces (see also bug 70683) or by blending in user's private settings from a user-private location. The drawback of sharing settings is that it can become hard to understand where a particular setting comes from; that's perhaps another reason for keeping the sharing mechanics UI-less (such that only advanced users could use this feature). "Sharing" could also be done without any UI at all. Consider Firefox, for instance, which provides UI for the "most important" settings only but stores all settings in user-editable files. It has well-known locations for the "installation settings" and the "user settings". If the sharing facility has no UI, this has the added advantage that shared Preferences are always read-only (since the only means of writing them is by editing a file). The workflow for admins could be 1. Create Preferences on a local project as needed 2. Copy local prefs file into team-shared location 3. Apply sharing to child projects On a very superficial review, it might be possible to hack class ProjectPreferences such that it performs more work when reading the .settings directory: For instance, read file ".sharing" which contains workspace-relative paths of additional locations to search when reading Preferences. If an additional file ".sharing.user" exists, it could point to a place with user-private settings. Or, for each *.prefs file, a corresponding *.prefs.user file could contain user-specific non-shared settings. Needless to say, similar support for sharing might be possible in class InstancePreferences for supporting settings shared among multiple workspaces.
Created attachment 117449 [details] Multi-project properties In order to be fair to the UI gang as well, here is a screenshot of the "multi project properties" dialog that we had in a former product of ours. The project properties dialog is extended by a project tree on the right-hand side. Below the tree you see a "project set" dropdown which worked similar to Eclipse Working sets (in order to use pre-defined sets of projects). Selecting a particular project in the tree on the right-hand side showed the properties of that project. Using the "set for checkmarked projects" dropdown allowed applying a setting to all projects in the tree that were checkmarked. I think that this UI was overly complex because of the unnecessarily fine granularity of settings: - Instead of specifying the scope of application by a dropdown beside each control, today I'd provide a simple "Apply to All" button that would apply all settings of the current page to all selected projects. - Instead of introducing a concept of "checkmarked projects", today I'd be using working sets to change the list of shown projects, and have the "Apply to All" button apply to all shown projects. The list of shown projects would be initialized with a project multi-selection in the project explorer when the properties action is fired. It seems, though that a change to the Eclipse Project Properties Dialog (i.e. adding a project tree to the right, and adding an "Apply to All" button) might allow for a multi-set operation in a backward compatible way, since the code would just need to iterate over all projects and perform the apply operation on each. Projects that don't support the displayed property page would get indicated gray in the project tree, and be skipped on an "Apply to All".
FYI we discussed this today in the context of e4 and came up with a suggestion on bug 255371 which sounds very exciting. Comments and help are welcome though our bandwidth for this may be limited...
CQ:WIND00165398
*** Bug 290560 has been marked as a duplicate of this bug. ***
In addition to being able to more easily set the project-specific preferences for existing projects I'd like to also be able to have the project-specific preference for a NEW project automatically set at the time the project is created... I could imagine the project inheriting its settings from either a template or the workspace's settings. We often find that people create new projects, write a bunch of non-complying code, check in to the SCM, and then we realize late in the plan that we have a ton of non-externalized strings or other such problems that prevent us from shipping.
(In reply to comment #10) > ... I could imagine the project inheriting its settings from either a > template or the workspace's settings. > I like the idea of inheriting project specific settings. Especially if this inheritance is by reference rather than by copy so that a change to the template will be automatically applied to all projects that inherits from it.
*** Bug 200213 has been marked as a duplicate of this bug. ***
*** Bug 486978 has been marked as a duplicate of this bug. ***
