Posted by Jesus Zazueta on Jul 12, 2013; 5:16pm
URL: https://forum.jogamp.org/Atomic-jars-in-Maven-Central-Gradle-build-system-tp4029555p4029589.html

Hello Mark. Jesus again.

I have managed to work around the conflict between JOGL's and Gradle's artifact storage/lookup strategy inside JGL by doing this:

1) Replaced JNILibLoaderBase's default loader action with my own:

JNILibLoaderBase.setLoadingAction(new GLBootstrap());

The relevant class is now in my master repository: GLBootstrap.java

2) Inside my loader action, I retrieved the current runtimes machine description and used that to scan the entire classpath for jars which match the current OS and Arch name. JOGL provides this via PlatformPropsImpl.osandarch

3) I then indexed every jar entry (which I'm naively assuming it to be .dll or .so files only, don't know for OSX :( ) inside the matched jar files to prepare my loader action to load the native libraries if/when they're requested by JNILibLoaderBase

It pretty much works for me and hopefully it might be something that could be integrated into JOGL as well after evaluating security (file access) and network communication concerns. I tested initially on Windows and I plan to try it on my linux machine later today.

One of the things that I realize is that I'm not really comfortable with the idea of handling native dependencies of features that I don't plan to use (for example, nativewindow's AWT native library when I'm only really using NEWT/SWT).

Hence my stubornness on wanting to use the atomic jars :P.

Anyway, I've updated my master repository at https://github.com/jjzazuet/jgl in case anyone's interested in helping me out.

I'm now going to switch the demos over to raw NEWT and leave my SWT code as an optional feature for JGL. After that, I'll see if I can launch the test shell via webstart.

Please let me know if there's anything else I could do or specify in the meantime.

Thanks again for your time and help!