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 84806 - Settings lost in project runtime config
Summary: Settings lost in project runtime config
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P2 blocker (vote)
Assignee: Jesse Glick
Depends on: 84668
Blocks: 42245
  Show dependency tree
Reported: 2006-09-13 15:17 UTC by Tomas Danek
Modified: 2006-10-23 16:40 UTC (History)
1 user (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 Tomas Danek 2006-09-13 15:17:22 UTC
NetBeans IDE Dev (Build 200609121800)
1.5.0_07; Java HotSpot(TM) Client VM 1.5.0_07-b02
Windows XP version 5.1 running on x86
en_US (nb); Cp1252

100% reproducible. P2 since this feature should work reliably in M3.

1) run ide with fresh UD
2) create new J2SE project with main class, add some output print e.g.
"Main.main running" to the main method
3) create class Main2 into the same package, fill in main method, add some
output print e.g. "Main2.main running"
4) expand project config combo, choose Customize...
5) create new profile (e.g. "2") and change it's main class to Main2
6) close project settings by OK
7) now run project with profile 2, then switch to default and run, then switch
back to 2 and run,...everything works.
8) close the IDE, clear userdir, and start IDE again
9) open your J2SE project
10) run it with default - OK, switch to 2 and run - OK, switch back to default
and run - and suddenly default contains settings from profile 2 - Main2.main is
Comment 1 Jesse Glick 2006-09-13 20:56:54 UTC
Some old code which changes main class in response to rename refactorings was
getting triggered (even though the source code was untouched) for some
mysterious MDR reason. It then got confused by the existence of the profile, and
thought the default profile's main class was an "old" class name and the
selected profile's main class was the "new" class name. Fixing by performing the
old-new comparison correctly; for now, disabling issue #42245 fix while a
nondefault profile is active.

BTW: was frequently, but not 100%, reproducible for me. Probably something to do
with timing of MDR activities.

Checking in;
new revision: 1.6; previous revision: 1.5
Comment 2 Tomas Danek 2006-09-14 12:46:55 UTC
right, works now. For usecase "refactoring(renaming) some profile's main class"
i will file some normal priority RFE.

verified in 20060914