Hi, on the top of NonStop OS I am not able to run the gradle. I am getting the following error. What should be done to get it fixed. --------------- /home/rajga/build/Nov_30_2011/hibernate/gradle-1.0-milestone-3/bin: sh gradle gradle[113]: ulimit: not found Could not query businessSystem maximum file descriptor limit:
FAILURE: Build failed with an exception.
What went wrong: Could not locate JNA native lib resource ‘/com/sun/jna/nonstop_kernel-IA64N/libjnidispatch.so’.
Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. -------------------
Thank you Peter Niederwieser ! if you mention less common OSes, can I know the list(of OS) which are supported in the latest milestone? If we can build LIBJNIDISPATCH.SO for our OS then how to build it?
The OSes that we regularly test against are Windows, Mac OS, and Linux, though Gradle is also known to work on other OSes like Solaris. Recent milestones also support OSes where JNA isn’t available, although some features may not work as expected then.
HOW CAN I GET LIBJNIDISPATCH.SO FOR NONSTOP OS?
I think you’d have to ask the JNA project (GitHub - java-native-access/jna: Java Native Access) to add support for your OS. Or maybe you could build JNA yourself. Anyway, our goal is to degrade gracefully if JNA isn’t available. Try the latest snapshot and tells us how it goes.
We’ve seen the same error with milestone-6 running on Windows 2008 Server R2 with MKS Toolkit 9.4. Sounds like the presence of MKS Toolkit makes Gradle think it’s running on a unix box (which it’s not).
Has this behaviour been changed in later (post m6) releases?
You should be able to influence which OS Java/Gradle detects by setting the ‘os.name’, ‘os.version’, and ‘os.arch’ system properties. One my Windows virtual machine, their values are ‘Windows 7’, ‘6.1’, and ‘amd64’, respectively.
@Rob, do you have the output from when you run Gradle? Can you include a stack trace for the failure by running with the --stacktrace command-line option.
Our build team found the problem. One of our .ksh scripts was calling gradle.exe when it should have called gradle.bat. Fixing that solved the problem. Thanks for the quick response.
Minor correction. Our .ksh scripts weren’t calling gradle.exe. The issue was that typing gradle into a ksh window will execute the linux version of gradle. We should have been typing gradle.bat.