NetBeans dumps its user config info into ~/nbuser32. However, the
MacOS X default for this sort of information is ~/Library/[AppName]. It
would be good for NetBeans to follow this and use the appropriate
location for this sort of info.
This can be solved by Netbeans launcher for Mac OS X. As a workaround you can
use -userdir switch and start Netbeans with
runide.sh -userdir ~/Library/netbeans
Clearly this will not be fixed for 3.2.
Duncan, if you know of a quick & reliable test for MacOS X from a shell script,
that would be helpful. Although there are plans to reimplement the bootstrap
process, perhaps for 3.3, in which case Java code could check for the platform
and make the decision that way.
Target milestone -> 3.3
Target milestone -> 3.3.1.
Target milestone -> 3.4
Target milestone was changed from '3.4' to TBD.
Assigning to Tomas so he can evaluate this and he maintains the mac os
Can this be fixed for 4.0 or 4.1 now that the platform specific code
has been added (thanks Tim)?
Currently, it creates ~/.netbeans/..., which is makes it invisible to
the Finder by default. The form ~/Library/NetBeans/... is much easier
for a novice user to find (to delete when installing a new dev build,
The old workaround presumes extensive Unix understanding to implement.
A new workaround is available (see
http://www.netbeans.org/issues/show_bug.cgi?id=48117), but still
requires Unix experience.
Passing this issue to Trung, since he owns the launch script, and
that's where presumably this should be fixed.
Is there anything we could do about it?
Just fix the launch script to default the userdir to /Library/NetBeans - there's already
conditional code in it to add arguments for the dock icon & such; it ought to be trivial to do
this there too.
Tim, did you mean ~/Library/NetBeans (with a preceding tilde)?
I hope this fix this bug:
replace in NetBeans.app/Contents/Resources/NetBeans/bin/netbeans:
case "`uname`" in
and add to NetBeans.app/Contents/Resources/NetBeans/etc/netbeans.conf:
Created attachment 26153 [details]
patch of my last comment
Please check my patch (id=26153). The same issue in project apisupport/harness is fixed with the same.
See issue 64570
Re-assigning. Milos, please review the proposed patch.
the patch itself works fine.
few more things to evaluate:
1. how to proceed with imports of settings ffrom older versions.
2. documentation impact
3. make sure the <path>/dev gets changed to appropriate version when releasing.
If you wanted to go crazy, I suppose the launch script could make ~/Library/netbeans a symlink to
~/.netbeans, if it exists - and that way settings import is automatic. I'm not saying it's the best way to
solve the problem, but it would work.
*** Issue 82819 has been marked as a duplicate of this issue. ***
*** Issue 71404 has been marked as a duplicate of this issue. ***
Change of the default owner.