This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
It is desirable to allow hint customization per project. In order to do so, some API enhancements are needed. The current version of the full patch is available here: https://bitbucket.org/jlahoda/nbpatches/src/per-project-java-hints/per-project-hint-settings The current built javadoc is here: http://bertram2.netbeans.org:8080/job/prototypes-spi.java.hints/javadoc/ High level summary of changes: 1. a new file type that holds settings is proposed - this is to allow to easily share settings between projects. A new module, editor.tools.storage is created to read and write this file. The reason this is separate from hints-related modules is that the storage format can be used by other tools (e.g. formatting) as well. I'll attach the DTD and an example of the file. 2. augmented spi.editor.hints with a way to get hints settings for a given FileObject (similar to other queries we have). 3. created spi.editor.hints.projects module that actually allows projects to specify the per-project settings. It also contains a support class(es) that allow to enable per-project hints for "standard" (i.e. J2SE Project-like) projects simply.
Created attachment 133468 [details] Tool configuration file DTD
Created attachment 133469 [details] An example file with hints settings.
I would like to ask for a review. Any comments are welcome. Thanks.
In view of the fact that the number of settings categories can grow (we have hints, on-save actions, formatting, possibly license headers?), and so can grow the number of respective configuration files under project directory structure, it might be good to introduce a naming convention for all such files. The point is to keep orientation in e.g. nbprojects/ as simple as possible. If all configuration files were named like, e.g., cfg_?????????.xml, they could be listed together in standard file system views and many a confusion would be prevented.
MK1: is the file assumed to be always shared across developers? or will we also allow dev-private settings? if so how will they interact? MK2: in case of formatting (the possible future case mentioned) how would the new format interact with the current way of sharing project formatting options? (Aux properties)
(In reply to comment #4) > In view of the fact that the number of settings categories can grow (we have > hints, on-save actions, formatting, possibly license headers?), and so can grow > the number of respective configuration files under project directory structure, > it might be good to introduce a naming convention for all such files. The point > is to keep orientation in e.g. nbprojects/ as simple as possible. If all > configuration files were named like, e.g., cfg_?????????.xml, they could be > listed together in standard file system views and many a confusion would be > prevented. I'll add a note about that into arch.xml and ToolPreferences' javadoc, if that is OK&enough. MK01: So far, my idea was to read the settings from one location only, either the global settings, or the settings file, or whatever other storage the project will choose. This is mainly because usecases for settings hierarchy seem minor to me compared to UI complexity they bring. If there is a strong enough usecase to support settings hierarchy, the current API I think allows the project to do that, and the API could be extended to make that easier. MK02: The formatting part is not really finished. I expected to provide general framework to allow the change of the per-project formatting here, not to actually do that. But my idea so far was that when the settings would be converted to file (on user's request), the Preferences based settings would be stripped (or ignored).
I updated the API in a few ways: -added a note about recommended config file name convention into StandardProjectSettings.createSettings' javadoc. -ToolPreferences.save is not mandatory anymore, is either saved on Preferences.flush() or automatically after a timeout (which makes the Preferences behave more similarly to other Preferences). "save()" is kept, as that makes saving UI properly easier. -added PerProjectHintsPanel.MimeType2Preferences, so that PerProjectHintsPanel can be used also without ToolPreferences (which is expected to be useful in the maven's case). Unless there are objections, I would like to integrate early next week. Any suggestions are welcome. Thanks.
Seems good to me.
One minor thing regarding the FileHintsPreferences.addChangeListener(). The static method probably will not work with WeakListener.
http://hg.netbeans.org/jet-main/rev/136f671ea6b7