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.
In my project I have two filesystems mounted (both are local directories), one with my source tree and another intended for compiler output. When I set Project->Settings->Compiler Types->(any compiler)->Target = True the compiler does correctly stick the .class files in the 2nd filesystem. HOWEVER, if I now make a change to a non-Main source file, save, then build the project (ctrl+shirt+F10)... or even explicitly compile this one file! (F9)... somehow the changes don't "happen". When I run the project (ctrl+shift+F6) an old class is clearly being loaded. When I check the filesystem I can see that the .class has in fact been recompiled (timestamp on touched class is correct). Thus, I suspect that the culprit is actually in the "running" machinery. Note one: I have ensured that an old version of the class I'm changing is not present on any mounted filesystem, in case you were wondering. Note two: This is a Swing application. I am not certain what "execution type" is being invoked when I hit ctrl+shift+F6.
UPDATE - doh! In spite of my claim to the contrary, there *were* old .class files in my src filesystem. The src filesystem was also mounted before the output filesystem... presumably the CLASSPATH used by the "running" function lists them in this order. NEW FEATURE REQUEST =================== When the compiler target directory is set, ensure that said target directory is listed in the runtime CLASSPATH *before* any src directories. This would greatly reduce the likelihood of being bitten by this "bug" I reported.
Will ask the user when the output dir follows the source one.
Target milestone -> 3.3
Well, I would like to remove the source entirely from execution classpath if the output is directed to another directory; but there may be some additional resources (e.g. .gifs) among the sources. Anyway, I'm bumping priority of the enhancement - the issue can be unnoticed by the user for a considerable time causing strange errors. I'm not sure about how it will be solved, though.
Target milestone -> 3.3.1.
Cleaning up before 4.0 planning
Target milestone was changed from not determined to TBD
New projects infrastructure could solve it, isn't?
This is solved by the new build system.