Community
Participate
Working Groups
I20100121-0800. Currently when we introduce a new setting (e.g. JDT Core problem) and the project is configured to use project specific settings, it uses the value as configured in the workspace because the new setting is not stored yet. We should check for new settings (e.g. by attaching ourselves to the builder) and generate a problem on the project that informs about this. Of course this would come along with a quick fix. The nice side-effect of this is that we can use it to advertise new settings through this mechanism.
ping
I'll put this on our 3.7 plan.
See also bug 319874
We've quickly looked into the implementation aspects of this bug, and here are some points to consider: - The UI decides how preferences are grouped into preference pages, so only the UI can decide when a preference is missing. - The UI already has a list of preference keys that per page, see e.g. ProblemSeveritiesConfigurationBlock#getKeys(). This list should only be present once in the system, but it shouldn't stay in a prefs UI class because that would make the classloader load too many classes eagerly, even if the user never opens the preferences dialog. A possible solution: - keep the list of JavaCore.COMPILER_PB_* strings somewhere outside the preferences framework - in the OptionsConfigurationBlock#get*Key(String) methods, add some lookup functionality, such that clients can later on find an existing Key; or turn Key into a proper value object and implement hashCode/equals - To avoid having to add a separate builder for .prefs files, we can just listen to IResourceChangeEvent#PRE_BUILD events. Need to use some caching to avoid re-checking the same files again and again, e.g. based on .prefs file modification stamp.
Markus and I discussed this again today and decided against it: - Each new preference would cause a failure on every project in the workspace or at least on those which have this new feature enabled. - This enhancement only makes sense if we would be able to offer a good story to fix the created problems. This is not easy especially for preferences that are nested. - A clean up that can be invoked from time to time might be more appropriate. We'd better invest in bug 194414 than fixing this enhancement.
