JOGL and GlueGen can not load native libraries from a fat-jar packaged executable Jar. Fat-jar is a method where all libraries and resources are unzipped and then zipped back up into one giant executable jar. It is not the beat way to do things but it is common. When GlueGen looks for native libraries it looks for the JAR that GlueGen came in, then looks for a jar in the same directory, using a naming convention including the architecture, and then gets native libraries from that jar. Emails about this: http://forum.jogamp.org/Loading-libraries-from-an-executable-JAR-is-seriously-hard-td3885657.html
Copied my reply fom the forum: +++ The current schema, one native JAR file per platform very well serves the traditional Applet/Webstart deployment since it saves bandwidth and it also serves most stand alone application. Having a fat JAR would at least require the native libraries to reside in a subfolder using our naming convention. Such implementation would be doable with minor changes to the current code. However, I don't see a conflict w/ Jar in Jar, which I personally would favor here. It also gives one the opportunity to use the original [signed] JAR files, so you can maintain the files origin and identity. Well, using a fat JAR here implies that in the JOGL layer, the fat JAR content is already 'known' and available to the classloader. Hence we can skip extracting files, but 'just' need to find the platform's subfolder and continue there (copy files to temp folder and allow them to loaded by the classloader). We may even be able to skip the copy part, if it is ensured that only one ClassLoader will access those libraries (no Applets .. ). Anybody out there who cannot live with the current use case, restricted to native Jar files per platform incl. Jar-In-Jar ? For sure this won't be done for RC6. Please add a bugreport (enhancement) with the content of your and my writings and we can vote/discuss it further. +++
P5, since it's not really required. Current native JARs per platform are available. Nevertheless, we (?) may implement this feature, anybody likes to volunteer ?
I don't have the time to help, and have also started down the jar-in-jar route anyway. I can note that while JOGL works with the Eclipse jar-in-jar resource loader it does not seem to work with one-jar, another very common jar-in-jar loader.
(In reply to comment #0) > Fat-jar is a method where all libraries and resources are unzipped and then > zipped back up into one giant executable jar. It is not the beat way to do > things but it is common. I understand your position but I have to warn readers about the risk of such a poor approach. If the .jar extension is associated to an archiver (WinRAR under Windows, Arch under GNU Linux), your fat JAR won't work, this archiver will open it and the final user won't understand what is wrong.
since jar-in-jar works and we have no prio nor resources for a single flat fat-jar, I close this bug for now.