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.
the comment above default_userdir property says as below: # ${HOME} will be replaced by JVM user.home system property when actually the ${HOME} is getting replaced by C:\Documents and Settings\Administrator\Application Data where as JMV user.home is C:\Documents and Settings\Administrator When I looked into app.cpp source file, I found that it is taking value from APPDATA value, as shown below: if (RegOpenKeyEx( HKEY_CURRENT_USER, "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders", 0, KEY_READ, &key) != 0) return NULL; char *path = GetStringValue(key, "AppData");
Comment was simply wrong, so fixing it. Current behavior is probably the best we can do. Reopen with patch if you think otherwise - cf. j2se/src/windows/native/java/lang/java_props_md.c#getHomeFrom* which is pretty complicated. Note that the generic launcher behavior intentionally matches that used by the NB IDE; major changes could be considered compatibility issues. committed Up-To-Date 1.6 apisupport/harness/release/etc/app.conf
> Note that the generic launcher behavior intentionally matches that > used by the NB IDE I verified it. this is not the case; in netbeans 5.0 IDE ${HOME} is replaced as: C:\Documents and Settings\Administrator where as in generic launcher which is provided by netbeans 5.0 platform harness, replace the same ${HOME} as: C:\Documents and Settings\Administrator\Application Data
Created attachment 30906 [details] For your reference I am attching netbeans 5.0 IDE's About Dialog
santhosh is right. There is a difference between the default userdir location used by the IDE and NB platform based apps on Windows. While adapting the generic app launcher from the NB IDE one, I followed the guideline suggested in issue #57798. I agreed with the suggestion, but didn't want to change the default IDE userdir location for compatibility reasons.
I had a look at issue #57798. the current behavior is confusing. it replaces ${HOME} with APPDATA I suggest 3 solutions: 1: replace ${HOME} with C:\Documents and Settings\Administrator or 2: rename HOME variable to APPDATA in conf file or 3: allow both HOME and APPDATA variables; you can put APPDATA as default if you want; but it gives users to either use HOME or APPDATA as per their taste; I prefere 3rd solution because it gives more freedom to user.
#2/#3 are probably unacceptable because the .conf file should be platform-independent. Re. #1, no opinion. Honza who is in charge of maintaining the Windows launchers these days? Could it be reassigned to that person?
Re: 1: replace ${HOME} with C:\Documents and Settings\Administrator Easy to do, but I'm afraid it might break future versions of existing apps that already rely on userdir in the APPDATA location. I don't quite understand the motivation behind this request. The notion of the ${HOME} property is vague on Windows anyway. There is no such default property in fact. The guideline for Windows apps is that application data (which is what userdir is for) should be stored in the APPDATA folder. I don't see why it's important to have the application's userdir placed in the upper-level folder. Re "ownership": There is no new owner yet. I need to talk to Tonda about it.
That's an odd thing to say, considering that the IDE does exactly this. It's entirely conceivable that 3rd party platform apps might want to retain the old HOME location for backwards compatability purposes as well, yes?
Re: "That's an odd thing to say, considering that the IDE does exactly this." True. However, the IDE has been doing this for years. Re: "It's entirely conceivable that 3rd party platform apps might want to retain the old HOME location for backwards compatability purposes as well, yes?" It's quite possible. The question is what is the ratio of the pre-5.0 platform based apps to the 5.0+ ones. The generic .exe launcher in 5.0 (and later) creates the userdir in APPDATA by default. I haven't seen a single complaint about this. Changing the default location back to ../APPDATA is likely to be an incompatible change for all apps created with the new apisupport starting with NB 5.0. I'd say the damage would be worse in this case.
jglick says: > #2/#3 are probably unacceptable because the .conf file should be > platform-independent. I don't think the conf file platform independent currently see the following comment in netbeans.conf # clusters' paths separated by path.separator # (semicolon on Windows, colon on Unices) #extra_clusters= that means I can't use same conf file on both windows and unix for example if I use cp:a or cp:p option in default_options, i have to use semicolon on windows and colon on Unices It is bad to say that command line arguments of java.exe are not platform independent
If you specify extra.clusters this necessarily has to depend on the platform because you have to find those clusters on disk in an arbitrary location. But the default config for a platform app is to use just clusters from *.clusters, simple dir names, and that is indeed independent of platform. The issue with ${HOME} is that the default config file actually has default_userdir="${HOME}/.${APPNAME}/dev" and this must be interpreted on any platform. Introducing a new variable like APPDATA would not work on non-Windows platforms.
Radim I think you own the Windows launcher these days. True? I don't have a strong opinion on this currently but I am inclined to close as WONTFIX for reasons previously outlined.
WONTFIX for this moment. Maybe we will change this in the future at once for IDE launcher as well as for harness but not now.