I have a simple JUnit test that I successfully run inside Eclipse on macOS Mojave. The class makes a JNA call to a dynamic library, so I had to set the Runtime environment variable DYLD_LIBRARY_PATH
When I try to run mvn test
both inside or outsite of Eclipse, they fail.
The reason, so I learned, is macOS' System Integrity Protection which wipes all DYLD
variables. However it must be possible to set them, somehow, since the JUnit test inside Eclipse works as designed.
I tried to "hack" the mvn
shell script which ar the very end executes:
exec "$JAVACMD" \
$MAVEN_OPTS \
$MAVEN_DEBUG_OPTS \
-classpath "${CLASSWORLDS_JAR}" \
"-Dclassworlds.conf=${MAVEN_HOME}/bin/m2.conf" \
"-Dmaven.home=${MAVEN_HOME}" \
"-Dlibrary.jansi.path=${MAVEN_HOME}/lib/jansi-native" \
"-Dmaven.multiModuleProjectDirectory=${MAVEN_PROJECTBASEDIR}" \
${CLASSWORLDS_LAUNCHER} "$@"
by setting the DYLD_LIBRARY_PATH
immediately before the exec
command, without success.
Also tried to patch $JAVACMD
to set the variable first, no luck.
What options did I miss (short of disabling SIP)?
I'm not looking for a general solution, running mvn
is my goal
Similar questions:
I found a solution, I don't like it, but it seems to work. The JNA call went out to load additional code that uses the @executable_path
annotation. Running Java, the executable is the JVM, not the original application and thus the JNA call would fail.
Linking the whole program directory (and cleaning up thereafter) did the trick for me. My call to mvn
looks like this:
#!/bin/bash
# Ugly hack to make mvn play ball
JAVA_HOME=/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home
for onelib in $(ls /Applications/HCL\ Notes.app/Contents/MacOS)
do
echo "Linking /Applications/HCL\ Notes.app/Contents/MacOS/${onelib}"
sudo ln -s /Applications/HCL\ Notes.app/Contents/MacOS/${onelib} ${JAVA_HOME}/jre/bin/${onelib}
done
# Maven test
mvn test
# Cleanup
sudo find $JAVA_HOME/jre/bin -maxdepth 1 -type l -delete
YMMV