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.
dev build 200707230000 I have a JUnit test for a module that uses JNI. I must run the test from a certain directory or else I get "java.lang.UnsatisfiedLinkError: libraryName.dll: Can't find dependent libraries". I can run the test just fine if it's located in the Sources folder as a standalone application but when I migrate it to JUnit and move the code to the Test folder it seems to ignore the "Working Directory" setting under project properties. So in a nutshell: JUnit should either make use of the working directory setting or (better yet) have its own separate working directory. I don't believe there is a way to resolve this within the test code itself.
Redirecting to "ide" component because I have a feeling I filed this against the wrong component. I've increased the priority to P2 because there is no known workaround and this totally prevents me from testing any JNI code.
What type of project do you use? (j2se, web, ...) Anyway, what's the way you use for loading the library?
Some hints: http://wiki.netbeans.org/wiki/view/NativeLibrariesInNetbeans?version=3
I am using a j2se project and System.loadLibrary() to load the library. The link you mentioned talks about paths for Netbeans modules but it isn't clear what you can do for normal user projects.
Worked last time I checked; see issue #47474, and your build-impl.xml which sets <junit dir="${basedir}" ...> Do you have steps to reproduce, preferably a stripped-down test case not involving JNI?
1) Modifying the "dir" attribute in <junit dir="${basedir}" ...> fixed the problem for me but obviously this isn't a workable solution because Netbeans regenerates build-impl.xml on a regular basis. 2) The last comment in issue #47474 explicitly states that junit will use the project basedir so it seems this is working "as designed" but I argue that this design is flawed because it did not take JNI into consideration. 3) It is not meaningful for me to produce a testcase not involving JNI because the root of the problem is that JNI code on Windows requires you to control the current working directory. There is a comment in issue #47474 that reads "Anyway your program should probably not rely on the current working directory, and your tests definitely should not." Unfortunately this technically impossible for JNI libraries under Windows. Configuring "java.library.path" enables System.loadLibrary() to find the initial DLL but if that DLL depends on other libraries then "java.library.path" is ignored and the current working directory is used instead. The Windows DLL search path is discussed here: http://msdn2.microsoft.com/en-us/library/ms682586.aspx
An alternative is to append to PATH prior to running the test but I think that changing the current working directory is a safer approach.
I suggest the following fix: 1) I will create new property junit.basedir 2) I will change the build-impl.xsl to set junit.basedir to ${basedir} when it's not set and change <junit dir="${basedir}.../> to <junit dir=${junit.basedir}.../> If someone needs to use different basedir for unit test (because of JNI) he simply puts junit.basedir=<path_to_basedir> into project.properties and the JNI code will work.
I've used the work.dir property for junit task, should work in the same way as in run. Checking in src/org/netbeans/modules/java/j2seproject/resources/build-impl.xsl; /cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/resources/build-impl.xsl,v <-- build-impl.xsl new revision: 1.98; previous revision: 1.97 done
What is the implication of using work.dir for junit? Does that mean that if I change the default work directory using the Project Properties window it will now affect junit as well? Or do I still need to set it by editing build.xml by hand?
Yes, setting the working directory in the customizer should be enough, no editing of build files nor property files is needed.
Okay, I'll give this a try and get back to you. I am also removing the keyword "INCOMPLETE", I hope this is okay.