Posted by gouessej on Apr 22, 2014; 7:59am
URL: https://forum.jogamp.org/Fat-jar-deployment-method-ant-recipe-tp4032213p4032222.html

hharrison wrote

After checking, I left out the newt/data/ folder from the jogl-all.jar, actually produces a null pointer exception as some default window icons are not found...only on X11 though.

There is an image in jogl.util.data.av too and there are some shaders in jogamp.opengl.shader. Why not rather including all class, png, glsl, vp and fp files?

hharrison wrote

The single-jar deployment is pretty attractive

It's attractive when the default archiver doesn't get in your way (WinZip, WinRar, Ark, ...).

hharrison wrote

, but I'll have a look at your native packaging tool and see what it offers.

It's still a "work in progress" feature but you can already use the tools that I will use under GNU Linux and Mac OS X. Microsoft Windows will be harder to support.

hharrison wrote

Currently we're delivering exe4j packaged executables, the fat jar is for everyone on non-windows for now.

Therefore, appbundler + Red Line + jpkg would just improve a bit the native integration, you wouldn't be bothered by the default archiver. exe4j is known to be worse than launch4j (not sure it handles relative paths correctly). I haven't tested jsmooth (it generates larger executables) and winrun4j. NSIS can be used for Java applications too.

Edit.: Keep in mind that you can't set the maximum heap size when using a single JAR without any script or Java Web Start whereas Red Line / jpkg / appbundler don't prevent you from doing that (in the script that runs "java -jar"). The fat "executable" JAR is nice when you can use your application with the default values of the JVM. Only a very few things can be set directly in the manifest.