Bug 225298 - Improve Management of Hints, Formatting and Other Settings That May Need to Be Shared Across Groups of Projects
Improve Management of Hints, Formatting and Other Settings That May Need to B...
Status: NEW
Product: editor
Classification: Unclassified
Component: Hints & Annotations
7.3
PC Windows 7
: P2 (vote)
: 7.4
Assigned To: uireviews
issues@editor
: UI_REVIEW
Depends on: 228495
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-24 16:47 UTC by Petr Somol
Modified: 2013-11-22 08:03 UTC (History)
5 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
License Headers panel in Project Properties + Template Manager dialog (142.47 KB, image/png)
2013-04-10 16:54 UTC, Petr Somol
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Somol 2013-01-24 16:47:11 UTC
In Tools->Options->Editor it is possible to specify global settings like Hints (selection of which hints to enable/diable) or Formatting in detail. Currently, the global Formatting definitions can be overridden per Project in Project Properties. By default in a new project the global formatting is used, but users can switch to project-specific formatting setting, what creates a local one-time copy of the global settings; the local settings are now persisted in project.properties. Once project-specific formatting is enabled, it is also possible to manually import formatting settings from another project. Formatting settings import is a one-time action that simply overwrites the current respective project-specific settings.

Jan proposes to extend Hints management to enable project-specific hints setting as well, but also points out that new use-cases should be considered:

- Formatting and Hints settings should be easily shareable across groups of projects, to simplify enforcement of the same rules across a team; the current mechanism of explicitly importing formatting settings from one project to another is too tedious and inflexible - a mechanism that would enable sharing a dedicated settings file (Jan proposed separate settings file for Hints and for Formatting) would be more practical

- settings within Hints category are currently all treated as equal, although there might be an intrinsic inner categorization among them. Various hint settings (and possibly their associated "correction" actions ?) can be considered to belong to various (possibly multiple) currently unsupported categories like Default Coding Style, Personal Coding Style, Team Coding Style, Minimal Code Quality Standard or Team Code Quality Standard, etc. It should be possible to easily share settings from just some such categories among a group of NB Projects. Similar categorization might be possibly considered for Formatting settings as well. 

In case of Hints, this type of improved management should cover the NB default Hints, but also the external hints from FindBugs and possibly others as well. Handling this is an open question. Another open question is how to handle the above with respect to other-than-Java project types and with respect to Maven projects.

As the number of possible hints or formatting settings grows in time, the settings management should cope well with old settings files that do not cover all currently available ones, etc. This seems to be no problem as the complete set of settings will always be accessible as global options, and the global settings can always be used as default in case project-specific settings are expected but incomplete.

--------------------------
Initial proposal (psomol):

Support for "sharing categories" would be added, to enable grouping of hints or formatting settings according to purpose (see Team Coding Style vs. Minimal Code Quality Standard, etc., above). Basic sharing categories would be predefined globally, but users would be able to define custom ones in Options->Editor->... (Global?). In Project Properties it would be possible to specify, which sharing categories would apply for this particular project. Also, in global Options, it would be possible to specify sharing categories which would apply always.

A dedicated settings file (separate from project.properties) would for each item (one Hint or one Formatting setting) store not only the information as till now, but newly also:

- to which sharing categories it belongs
- for which project types this particular item is relevant
- in which tooling context it is relevant (NB default, FindBugs, etc.)

This information would be surfaced in Options->Editor->Hints (or Formatting); each item would be assignable to one or multiple sharing categories, with reasonable defaults predefined. Relevance to project type and to tooling context would of course be predefined and unchangeable for each item. The same would be possible in Project Properties.

Project-specific settings would be stored in a dedicated metafile by default inside project. However, projects should be able to alternatively reference a chosen setting file stored anywhere.

From UI perspective the Project Properties would allow to specify which settings to apply:

- use global default settings (default), if a project-local settings metafile exists inside project, it is ignored

- use project-specific settings (if not existing, a local settings metafile would be created inside project, initialized to a copy of global settings)

- apply project-specific settings, from a referenced file (i.e., read as many overrides to global defaults from the referenced file if such exist)

In project.properties there would be just a single (optional) property "reference.to.settings.file". On project open the settings load sequence would be: 
1) if "reference.to.settings.file" exists, try to load the file and take from it all applicable overrides of global defaults. 
2) If property "reference.to.settings.file" does not exist, try to find local settings file inside project location. If it exists, try to load the file and take from it all applicable overrides of global defaults. 
3) Otherwise use global defaults.
Comment 1 richgunther 2013-01-24 19:19:13 UTC
This seems like a great idea from the perspective of providing flexibility, but my main question is whether or not users will actually use this added flexibility.  Is this a corner case?

In any case, if we were to implement something like this, I think we would need to make switching between the hint modes VERY simple, i.e. not requiring the user to go into options to switch.  Perhaps a selector of some sort in the editor toolbar?  Couldn't it be the case that during certain coding tasks the user wants to use global hints and in others project-specific hints?

Rich
Comment 2 Petr Somol 2013-01-25 08:47:15 UTC
Jan would probably give better founded comment about how frequent the usecase would be, but as I understand it, the list of "sharing categories" would be customized not too frequently. The functionality would probably make most sense in production environment with larger teams, where for a certain project certain settings' change could thus be easily adopted and shared. An example of such situation is what I just observed in JavaFX team - in the autumn they introduced rules about which FindBugs warnings must be fixed in production code for the next release. With a functionality discussed in this issue, if it was available, such a decision would lead to creation of just one settings file that would be referenced from each sub-project; the IDE would thus show exactly those warnings (and none else) to each team member that this particular release cycle aims at fixing. When the team moves to another release or major project, the settings file can be simply adjusted and reused.

Generally, sharing among team members is probably an even bigger issue than this. It would make sense to enable centralized maintenance of the IDE in full. So that for a large team there could be just one shareable configuration prepared by the responsible body just once, and then easily shareable and centrally maintainable. Such configuration would also include whatever other information would need to be shared in a team (not only formatting and hints, but also proxy settings, extension list, banned extension list, customized templates, predefined copyright files, etc. etc.).
Comment 3 richgunther 2013-01-28 16:52:35 UTC
Yes, it seems like we're trying to solve a number of issues here, so perhaps its best if we split up the use cases instead of trying to find a one-size-fits-all solution.

Also, another question: is it possible that we could get conflicting logic here if we had two sets of hint logic in use?  What I mean is, what if the global hints said "show me this style of hint" and the project-specific one said "do not show me this style of hint".  Is there a presumed hierarchy to this that we'd need to enforce?

Rich
Comment 4 Jan Lahoda 2013-01-29 10:13:03 UTC
Thanks Petr for writing this up, and sorry for delayed answer.

The usecase (for "hints" at least) is that each developer working on a project automatically gets the same environment (more or less), so that he/she can produce code in the same code style as the rest of the team. A variant of this usecase is one developer working on multiple projects with different code styles.

I don't think the user is going to switch between project-specific and global often: when a project has per-project settings enabled, these should be used.

Regarding hierarchy between the settings, I think we should try to avoid multi-level hierarchies as much as possible, as these tend to over complicate the UI. There are two cases related to settings hierarchies I can see:
-if the per-project settings do not contain a particular setting, some kind of default needs to be used. The possibilities I see are:
a) use "disabled" (valid for hints, but may not be reasonable some settings)
b) use "global default" - i.e. the setting to which the global settings are initialized
c) use current global setting - i.e. whatever is currently in the global settings
I incline to "b", although I can see some value in the other approaches as well.
-the user might want to override a per-project settings only for him- or herself. I don't think this is a strong usecase and I am not convinced it is strong enough for the UI clutter this would cause. So I would propose to skip this usecase for now.

In general, I would personally prefer to keep this as simple as possible. I think we should define which settings are shareable and which are not, and allow to independently set logical (predefined) groups of the shareable settings per-project (e.g. formatting, hints). 

One thing I realized is that it would make sense for the "On Save actions" to be set per-project.
Comment 5 markiewb 2013-02-08 19:45:58 UTC
See also http://netbeans.org/bugzilla/show_bug.cgi?id=181726 "Make hints configurable per project"
Comment 6 Jan Lahoda 2013-02-28 15:20:22 UTC
FYI: I've set-up a continuous build containing my original per-project-hints experiment here:
http://bertram2.netbeans.org:8080/job/prototypes-spi.java.hints/lastSuccessfulBuild/artifact/nbbuild/
Comment 7 Petr Somol 2013-03-19 10:37:31 UTC
Created a related wiki page: http://wiki.netbeans.org/UEXOptionsManagement
Comment 8 Petr Somol 2013-04-08 13:55:18 UTC
Note that the new License sharing functionality seems to fit into the scope of this issue as well. See issues Issue #226773 and Issue #226774. I am going to update [UEXOptionsManagement] wiki.
Comment 9 richgunther 2013-04-09 15:34:28 UTC
@Petr: can you upload screenshots of the license management area as-is in NB now, and how it would change if we were to deal with it in a similar way to hints, formatting, etc?  I want to make sure we're being consistent, because it sounds like this could creep into other areas in the future.

Thanks!
Rich
Comment 10 Petr Somol 2013-04-10 16:54:05 UTC
Created attachment 133434 [details]
License Headers panel in Project Properties + Template Manager dialog

In response to Comment #9 I add a screenshot of current License Headers panel. The attachment also contains another screenshot of what appears when user clicks Edit global licenses.
The panel resembles the ones discussed in hints and formatting context, but the logic may currently differ a bit. When Use global license is selected, the combo offers a list of prepared license headers. Use project location allows to store a custom license in a file under project structure, in concert with what we discussed so far.
The Template Manager looks fairly confusing to me in this context - I could not find how for instance the Default license can be modified etc.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo