Bug 121429 - Search for the .netbeans directory on the current directory first.
Search for the .netbeans directory on the current directory first.
Status: NEW
Product: platform
Classification: Unclassified
Component: -- Other --
5.x
All All
: P2 (vote)
: 6.x
Assigned To: issues@platform
issues@platform
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-08 01:39 UTC by i30817
Modified: 2009-01-06 14:24 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description i30817 2007-11-08 01:39:30 UTC
I'm just really tired of permanently having to reconfigurate netbeans each time i move the computer (i keep it in a
pen). Is it possible to redirect the permanent directory like this:
private File netbeansHome = new File(".netbeans");
if(!netbeansHome.exists() || !netbeansHome.isDirectory())
   netbeansHome = new File(System.getProperty("user.home") + File.separator + ".netbeans";
//later, elsewhere
if(!netbeansHome.exists())
//mdir create/fill config
else
//read config

I imagine there is only one place to get the netbeans home.
Comment 1 Petr Nejedly 2007-11-08 16:57:50 UTC
Would it help to just support relative path in the etc/netbeans.conf (so you could have userdir next to the installation)?
This would support the case of having both NetBeans and the userdir on the flash disk.
Is this actually your use case?
Comment 2 i30817 2007-11-08 18:33:20 UTC
Actually yes and it already does :| I found this out after posting.
However i first tried to use the netbeans directory itself like this:

netbeans_default_userdir=".netbeans/6.0beta2"
So that the default location of the cache and preferences was the
netbeans directory itself. However that was not permitted (only
visible on the command line, just fails silently otherwise).

so i just used
netbeans_default_userdir="../.netbeans/6.0beta2"
and created a directory tree
netbeans\netbeans
netbeans\.netbeans
netbeans\svn

to just have all the things that netbeans uses in one mobile directory
This is almost perfect except that svn is an external program and
still stores its configuration files and certificates on the user
directory. I know that netbeans replaces the config files but i didn't
notice that for the certificates (it also doesn't let me accept
certificates without a CA, so i have to go to the command line to
store them, and thus NEED the svn configuration on the home directory)
Except for those three things things are allright. I would also
advertise that this is possible on the readme or wiki.
Comment 3 i30817 2007-11-08 18:41:23 UTC
Opps spoke too soon. In linux it gives an exception with this config file

# ${HOME} will be replaced by JVM user.home system property

#netbeans_default_userdir="${HOME}/.netbeans/6.0beta2"

netbeans_default_userdir="../.netbeans/6.0beta2"




# Options used by NetBeans launcher by default, can be overridden by explicit

# command line switches:

netbeans_default_options="-J-Xverify:none -J-client -J-Xss2m -J-Xms32m -J-XX:PermSize=32m -J-XX:MaxPermSize=200m
-J-Dapple.laf.useScreenMenuBar=true"

# (Note that a default -Xmx is selected for you automatically.)



# If you specify the heap size (-Xmx) explicitely, you may also want to enable

# Concurrent Mark & Sweep garbage collector. In such case add the following

# options to the netbeans_default_options:

# -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled -J-XX:+CMSPermGenSweepingEnabled

# (see http://wiki.netbeans.org/wiki/view/FaqGCPauses)



# Default location of JDK, can be overridden by using --jdkhome <dir>:

#netbeans_jdkhome="/path/to/jdk"



# Additional module clusters, using ${path.separator} (';' on Windows or ':' on Unix):

#netbeans_extraclusters="/absolute/path/to/cluster1:/absolute/path/to/cluster2"





bash-3.2$ ./netbeans  &
[1] 4391
: command not foundnetbeans.conf: line 4: 
: command not foundonf: line 5: 
: command not foundonf: line 10: 
: command not foundonf: line 16: 
: command not foundonf: line 19: 
java.io.IOException: No such file or directory
        at java.io.UnixFileSystem.createFileExclusively(Native Method)
        at java.io.File.createNewFile(File.java:850)
        at org.netbeans.CLIHandler.initialize(CLIHandler.java:514)
        at org.netbeans.CLIHandler.initialize(CLIHandler.java:346)
        at org.netbeans.MainImpl.execute(MainImpl.java:180)
        at org.netbeans.MainImpl.main(MainImpl.java:75)
        at org.netbeans.Main.main(Main.java:75)
java.io.IOException: No such file or directory
        at java.io.UnixFileSystem.createFileExclusively(Native Method)
        at java.io.File.createNewFile(File.java:850)
        at org.netbeans.CLIHandler.initialize(CLIHandler.java:514)
        at org.netbeans.CLIHandler.initialize(CLIHandler.java:346)
        at org.netbeans.MainImpl.execute(MainImpl.java:180)
        at org.netbeans.MainImpl.main(MainImpl.java:75)
        at org.netbeans.Main.main(Main.java:75)
java.io.IOException: No such file or directory
        at java.io.UnixFileSystem.createFileExclusively(Native Method)
        at java.io.File.createNewFile(File.java:850)
        at org.netbeans.CLIHandler.initialize(CLIHandler.java:514)
        at org.netbeans.CLIHandler.initialize(CLIHandler.java:346)
        at org.netbeans.MainImpl.execute(MainImpl.java:180)
        at org.netbeans.MainImpl.main(MainImpl.java:75)
        at org.netbeans.Main.main(Main.java:75)
java.io.IOException: No such file or directory
        at java.io.UnixFileSystem.createFileExclusively(Native Method)
        at java.io.File.createNewFile(File.java:850)
        at org.netbeans.CLIHandler.initialize(CLIHandler.java:514)
        at org.netbeans.CLIHandler.initialize(CLIHandler.java:346)
        at org.netbeans.MainImpl.execute(MainImpl.java:180)
        at org.netbeans.MainImpl.main(MainImpl.java:75)
        at org.netbeans.Main.main(Main.java:75)
java.io.IOException: No such file or directory
        at java.io.UnixFileSystem.createFileExclusively(Native Method)
        at java.io.File.createNewFile(File.java:850)
        at org.netbeans.CLIHandler.initialize(CLIHandler.java:514)
        at org.netbeans.CLIHandler.initialize(CLIHandler.java:346)
        at org.netbeans.MainImpl.execute(MainImpl.java:180)
        at org.netbeans.MainImpl.main(MainImpl.java:75)
        at org.netbeans.Main.main(Main.java:75)
/var/log/messages.log (No such file or directory)ta2
        at java.io.FileOutputStream.open(Native Method)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
        at org.netbeans.core.startup.TopLogging.defaultHandler(TopLogging.java:312)
        at org.netbeans.core.startup.TopLogging.<init>(TopLogging.java:130)
        at org.netbeans.core.startup.TopLogging.initialize(TopLogging.java:170)
        at org.netbeans.core.startup.TopLogging.initialize(TopLogging.java:151)
        at org.netbeans.core.startup.CLIOptions.initialize(CLIOptions.java:207)
        at org.netbeans.core.startup.Main.start(Main.java:246)
        at org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:110)
        at java.lang.Thread.run(Thread.java:595)
Your user directory may not be inside your NetBeans installation directory.

[1]+  Exit 1                  ./netbeans
Comment 4 i30817 2007-12-11 22:21:05 UTC
I think i found at least 3 cases for the bug.
One is that it was obviously looking in the wrong directory in linux (or maybe in windows too).
The script seems to take as "base" directory to relativize the .. etc as the netbeans\bin directory (windows maybe uses
\netbeans)
Also the netbeans.conf file (and maybe others) get confused when parsing in a linux envoriment if the config file was
created on windows.
Specifically
/media/disk/ide/.netbeans/6.0
becomes
/media/disk/ide/.netbeans/6.0
 (there is an invisible char at the end, most likely \r)
even if declared like this:
"/media/disk/ide/.netbeans/6.0"\r\n
The other problem seems to be a completly braindead ubuntu/debian thing even with the normal(ubuntu) or superuser it
complains about not being able to create a directory (maybe the sh file changes it ?), but copy it into the local disk
and suddenly its as smooth as silk (except the \r bug above).

Why don't you use the default java behavior of using the file separator fist found? And how come a "path"\r\n is not
limiting the path to the enclosed path?
Comment 5 i30817 2007-12-11 22:30:43 UTC
Sigh. Another way to activate the java.io.IOException cascade is to use the "make link option of nautilus on the
.netbeans sh file on the bin directory itself, and move it another place. It is unable to cope.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo