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.
jdk-1.5 windows 2000 4.0 daily 11/7/2004 1. log into windows 2000 as a user with admin privileges 2. install netbeans to some directory 3. ensure install directory only has read priveleges for all other users. 4. log out and log back in as a restricted user 5. start netbeans 6! try to compile a project. you get a build error. see the attached debug ant output. the problem is that netbeans tries to create a temporary directory inside the working directory, which is the install directory and not writeable for the user. another problem is that under normal ant output, there is no clue given as to why the build failed. it simply says, 'BUILD FAILED'. at least the exception summary should be given. a workaround seems to be to modify the shortcut for netbeans so that the working directory is some directory where the user has write privileges. i have no idea if that breaks something else. a better solution would be to properly specify a correct parent directory for the temporary directory. i assume the proper location is the netbeans default userdir.
Created attachment 18878 [details] ant debug output
forgot to mention that i installed netbeans using the windows installer. if the netbeans working directory is supposed to be something other than the install directory, the problem lies with the installer. interesting, however, that netbeans works on the linux side without being in a specific directory when starting. why is the code different?
Appears to be an Ant problem in the first place. Why should it create a temporary file in a working dir instead of a temp dir?
The version of DefaultCompilerAdapter.java in Ant 1.6.2 is http://cvs.apache.org/viewcvs.cgi/ant/src/main/org/apache/tools/ant/taskdefs/compilers/DefaultCompilerAdapter.java?rev=1.41.2.6&view=markup and has in executeExternalCompile File userDir = getJavac().getTempdir(); if (userDir == null) { String userDirName = System.getProperty("user.dir"); userDir = new File(userDirName); } tmpFile = fileUtils.createTempFile("files", "", userDir); Why it uses this odd way of getting a temp dir, I have no idea. In fact I had already independently patched this in my local copy of Ant to read simply tmpFile = File.createTempFile("files", null, getJavac().getTempdir()); which would not pose a problem. I will try to commit that for future Ant versions, but the problem with 1.6.2 remains. Details: the <javac> task, if running in forked mode (e.g. you are compiling against a non-default Java platform) *and* running with a command length above 4096 characters, presumably meaning you have a project with a lot of files in it or a large classpath, will try to store arguments in some temporary file passed as e.g. javac @argsfile This is fine, but 1.6.2's choice of temporary dir defaults to ${user.dir}, i.e. Ant's current working directory, which is arbitrary when run from the IDE - currently may be the NB installation dir, but that is probably platform-specific. Possible workarounds: 1. Set the working directory of the IDE to be something writable, e.g. the system's temp dir. Hard to enforce, though; depends on which launcher is in use, etc. And I'm not positive what else this change might affect. 2. Set tempdir="${java.io.tmpdir}" on all uses of <javac> in the project's build script. Should work, though it is a little ugly, and will be obsolete (though harmless) as soon as my patch is in an Ant release. Would need to be done in all project types (so for D, j2seproject and web/project). Candidate for a 4.0 HR fix, I suppose. Re. message output in case of error - don't know much about it, would have to see an output log, but normally Ant at regular verbosity just prints an exception message or something, and prints a full stack trace only with -verbose or -debug, under the assumption that these are not *normally* user-level errors. I will also patch DCA.java to try to print a more helpful message such as Error creating temporary file: C:\Program Files\netbeans-4.0dev\files69258098 (Access is denied)
Can certainly fix for 4.1, up to QA for 4.0.
Checking in build-impl.xsl; /cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/resources/build-impl.xsl,v <-- build-impl.xsl new revision: 1.46; previous revision: 1.45 done
Diff: http://www.netbeans.org/source/browse/java/j2seproject/src/org/netbeans/modules/java/j2seproject/resources/build-impl.xsl.diff?r1=1.45&r2=1.46
The same fix needs to be done for Web too. Also there might be other tasks which behave similarly. <java>? Issue 51372 is about the same problem for <javadoc> task, but it is planned for 4.1.
<java> has no support for reading opions from file. The <javadoc> can be rewritten to use useexternalfile attribute.
Not a common scenario, workaround exists ->P2. Release note for 4.0.
Note: <javac> bug fixed for 1.7 at least: http://issues.apache.org/bugzilla/show_bug.cgi?id=29391
A correction: issue #51372 does not appear to be the same issue. Javadoc.java in ANT_162 has tmpList = fileUtils.createTempFile("javadoc", "", null); which should be fine.
Waiver approved for 4.0.