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.

Bug 206159 - new custom configuration doesn't inherit settings from default configuration
Summary: new custom configuration doesn't inherit settings from default configuration
Alias: None
Product: javafx
Classification: Unclassified
Component: Deployment (show other bugs)
Version: 7.1
Hardware: PC Windows 7
: P2 normal (vote)
Assignee: Petr Somol
: 205691 (view as bug list)
Depends on:
Blocks: 204756 204760 208575 208577
  Show dependency tree
Reported: 2011-12-08 18:17 UTC by Stepan Zebra
Modified: 2012-02-17 15:34 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Stepan Zebra 2011-12-08 18:17:30 UTC
Product Version: NetBeans IDE 7.1 (Build 201112071828)
Java: 1.7.0_02; Java HotSpot(TM) Client VM 22.0-b10
System: Windows 7 version 6.1 running on x86; Cp1252; en_US (nb)

Newly created run configuration for JavaFX project resets all run settings. Expected behavior is to inherit settings from current default configuration.
Comment 1 Petr Somol 2012-02-03 13:53:39 UTC
first part of fix (out of four) in jetmain:
Comment 2 Petr Somol 2012-02-03 14:50:33 UTC
second part of fix (out of four) in jetmain:
Comment 3 Petr Somol 2012-02-07 14:35:04 UTC
*** Bug 205691 has been marked as a duplicate of this bug. ***
Comment 4 Petr Somol 2012-02-17 15:22:26 UTC
Instead of adding two separate lesser fixes as announced in Comments 1 and 2 I decided to rewrite Run Config support in FX Project from scratch. The respective changeset is:

The reason was the ever growing number of minor issues that had not been discovered before and the increasing difficulty to deal with the original code. The original code had been originally replicated and modified from SE Project type. In SE, however, the complexity of property management was lower (no preloaders, no application parameters of two types, no browser selection). Accordingly, there had been no need for specialized config property management layer. This has been added now in form of JFXConfigs inner class in JFXProjectProperties.

Some of the undocumented issues now corrected
- not all arguments had been passed before
- manual overrides of properties in private property files had been lost after edits in project property dialogs
- numbering of parameter encoding properties was inconsistent and misleading (same property name was used across configuration files but this was not used to override because parameter properties follow different logic)
- logical groupings of related properties was not always preserved (with a single preloader related properties either all need to be defined or none should be defined, otherwise the information allows for logically faulty treatment)
- property persistence logic was arbitrary (it was not consistently defined what happens when user changes a property in default config to the same value as the same property has in some non-def config. Should the instance in non-def config be erased or preserved ? now this can be programmatically defined)
- etc.

Finally, I changed this bug's priority from P3 to P2 to express the extent to which the necessary changes have affected FX project code as well as the extent of changes in user experience related to run config management.