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.
There is no way how default values can be defined for settings in the configuration. Settings for some ProjectObject are constructed according to the inheritance tree defined by particular modules, but there is no common root of this hierarchy which modules could use to put defaults in there. There should be such place defined for each configuration type (it will be used by all configurations created by user), but modules need to be able to use similar place for particular configurations which they pre-define in the nature. The concept is shown on the picture below, default values should be stored in folders marked by (*) an asterix, these folders should be available for both configuration types and for specific configurations. That would require to move the registry of setting contexts of particular ProjectObjects under the FileContexts folder (**), it would also allow to have non-file based settings stored in contexts (folders) created by modules directly under the configuration's folder. Settings | - Defaults | - Configurations | - <configuration_type> | - Defaults (*) | - <configuration_name> | - Defaults (*) | - org-netbeans-modules-java-settings | | - usedPlatform.settings | | - FileContexts (**) | - someIDofProjectObject (This is also described in the document http://projects.netbeans.org/proposals/configurations/implementation.html, section 'Settings implementation'.)
I understand the purpose of having a Defaults folder under each configuration type folder: when a setting is not defined in a configuration, its value is taken from the Defaults folder of the same type. But what is the purpose of (1) The Settings/Defaults folder? (2) The Defaults folder inside each configuration? For 1, a setting can only belong to a single configuration type, so there already is a unique "fallback" place for any setting; the configuration type defaults folder. For 2, is there a reason modules can't simply set the setting itself in the nature - I expect nature layers to have lower priority for merges than the project's own layer, but perhaps that's not the case? In other words, my nature should be allowed to set a setting in a configuration, let's say Build/ReleaseConfig/debug.settings; this becomes the default and if the user changes it for the project, it gets written in the project file which then overrides the nature definition. Is this not the case? A quick note on performance. I first assumed that the way to implement this is to add additional places to look for settings - e.g. additional Contexts for the ProxyContext. This means every setting lookup (frequent operation) has to look in several additional places - at least for undefined settings (which I suspect will be a common case). You suggested the common user case for this is that when you create a new configuration, you want default values to be used. Perhaps at configuration creation time, we look up the settings and copy them in? So in other words - we only look in the configuration settings folder itself. But when you create the configuration, we consult the various Defaults/ folders and apply settings found in them to the configuration. That has the disadvantage that if the Defaults change in the future, the project will continue using the original values. (This is also known as a feature - stable/predictable builds even after upgrades :)
I've implemented this, but I get failures in two ProxyContext tests that I don't quite understand. See issue 28064 for details. I've attached a patch in unified diff format which implements this. The fix is simple; it adds additional contexts as delegates in the proxy context; one for each Defaults/ folder associated with a configuration type. There is also a new ConfigurationManagerTest which checks default values in configurations and makes sure this works. I also added an entry to the Project File System document which describes the new /Defaults folder under each configuration type folder. Note that there are only folders for configuration types; no global ones and no per-configuration ones; see my comments/questions from October 9th for a reason.
Created attachment 7729 [details] Patch which implements /Defaults folders
Created attachment 7730 [details] Datafile; add as test/unit/src/org/netbeans/modules/projects/configurations/data/defaultsettings.project
Done. I've applied Tor's patch with small fix solving problem described in issue #28064.
verified
Vita already verified
As described in http://www.netbeans.org/servlets/ReadMsg?msgId=619519&listName=nbdiscuss the current work on projects prototype has been stopped. Marking issue as CLOSED.