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.
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.
first part of fix (out of four) in jetmain: http://hg.netbeans.org/jet-main/rev/c0d76f5f34b1
second part of fix (out of four) in jetmain: http://hg.netbeans.org/jet-main/rev/748091c4a547
*** Bug 205691 has been marked as a duplicate of this bug. ***
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: http://hg.netbeans.org/jet-main/rev/199db8dfae04 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.