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.
for every maven based project (which don't have nbproject/private folder by default) the profiler creates the nbproject/private/profiler path without an obvious reason (there no data in there anyway.)
The reason is that this is a default storage for all project-based data: profiling configuration, attach settings, snapshots etc. Could you please suggest better place to store these data for maven-based project? Anyway, I don't think this is a P3 problem unless some functionality is broken. Lowering priority - please raise again if you know about any problems caused by creating the folder not described in this issue.
back to P3, for cvs/subversion based maven projects the folder is suggested to be added to the versioning system, because maven project don't mark nbproject/private or nbproject for that matter as nonshareable. And it's not a default storage for all projects. There is no such thing. If there is one than it's probably org.netbeans.spi.project.CacheDirectoryProvider in project's lookup that shall denote the directory where to put cache information. However please note that implementing this interface is non-normative for projects. primarily annoying is the fact that profiler creates this directory, even if no profiler action was invoked on that particular project and no data is actually stored there.
The data is not cache, this the profiler project settings. In the same way project itself store its setting in nbproject/private. The real problem is that nbproject/private should be ignored by cvs/subversion by default.
I disagree. The "real" problem as far as I'm concerned is that profiler creates a folder that is: 1. not holding any data thus is unnecessary. 2. at the wrong location i'm willing to argue about 2. but 1. is a no-brainer and profiler should store the data only when it has something to store.
Agreed with Miloš: that the folder should not be created until there is something to put in it; and it is in the wrong place anyway - see CacheDirectoryProvider and AuxiliaryConfiguration Javadoc. Modules not using ant/project are not permitted to assume that the folder name "nbproject" has any meaning. This is a serious annoyance when working with Maven projects, enough for me to want to simply disable the profiler modules. See issue #102648. Would be P2 if mevenide had a more official status, I think.
Typo. And please reevaluate.
I agree that using project-specific cache directory is better than a hardcoded one. But this will require large changes in Profiler code affecting all its features. This is much more an enhancement than a bugfix from the Profiler point of view. I'm afraid we won't be able to implement it for 6.0, that's why already evaluated as *future*. For 6.0 it's possible to check if lazy-creating the hardcoded nbproject/private/profiler when really needed is possible without any dangerous sideeffects. Would this work better for you?
Well, fixing #1 without #2 would certainly be a good start, as I am far more likely to open a Maven project then to profile it. (Not sure if profiling a Maven project even works to begin with.)
This issue is extremely irritating and has repeatedly corrupted my CVS checkouts. Please address for 6.0.
When I open an otherwise unmodified (or lightly modified) Hudson checkout with dozens of subprojects (project group type 'master project' or 'folder of projects'), immediately nbproject/private/profiler/ dirs are created under *each and every* POM project, and every .cvsignore is correspondingly rewritten to ignore nbproject. To revert all of these changes in bulk will take some shell-script wizardry (and risk accidentally reverting real changes). There is no apparent workaround. And all of this is just because I have the profiler modules installed - I never used them on Hudson at all, so they have a net negative value so far as these projects are concerned. This feels like a P2 to me. I'm sure at least part #1 of this bug is not so difficult to fix; I would fix it myself if your sources were available, but I can't. Please reevaluate.
Empty directory creation will be addressed for 6.0.
Now the nbproject/private/profiler directory isn't created until profiler is invoked somehow (Select Profiling Task dialog opened or some Profiling Point created). Fixed for Beta2.
Thanks!
Filed issue #147929 for part 2.