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.
I just found that if I run the Profiler on an autoproject, it creates a nbproject/private/profiler/configurations.xml file, polluting the project directory. Do _not_ assume that there is an nbproject/ subdir of a project or that you are permitted to create one. Use ProjectUtils.getPreferences if you need to associate some module-specific metadata with a project.
Not for 6.7.
The Profiler is violating a basic project system design principle and it results in a major bug for autoprojects. If you don't have time to fix it, can I?
We know about the problem, we were going to fix it as a part of profiler/IDE integration rewrite for 6.8. Unfortunately it looks like it's not a priority now... Feel free to fix it yourself, but please provide a patch here before integrating it - we'll review and test it. Thanks.
Things that need to be fixed (all apparently in main profiler module): 1. IDEUtils.getProjectSettingsFolder needs to be rewritten: 1a. Name should change to indicate that it may be used for storing snapshots and the like but should not be used for settings. 1b. Should use CacheDirectoryProvider going forward. 1c. For compatibility it can return nbproject/private/profiler/ if this dir already exists, but should no longer create it. 1d. Return value needs to be considered. In some places it is written to return null now. Callers are not expecting null. Probably should be changed to always throw IOException if it cannot provide a folder. 1e. getProjectFromSettingsFolder also needs to be rewritten accordingly. 2. ProfilerSettingsManager, ProfilingPointFactory, and NetBeansProfiler should: 2a. Use ProjectUtils.getPreferences going forward for keeping settings, not IDEUtils.getProjectSettingsFolder (or whatever its new name is). 2b. For compatibility, may read from nbproject/private/profiler/*.xml when the appropriate file already exists, but should then delete that file and store the settings using Preferences. Let me know if you object, else I will try to prepare a patch that does the above.
Part 2 is looking like too much work, and probably something module owners should do. (OQL queries also apparently have their own XML properties storage which ought to be rewritten to NbPreferences.) Instead I will just prepare 1b/1c. (To 1d, it seems that return value is intended to be non-null if create is set.)
Created attachment 84680 [details] Proposed patch
core-main #8df200ec0fdb
*** Issue 147929 has been marked as a duplicate of this issue. ***