Re: appbundler jogl jnilib dylib one-jar confusion
Posted by Sven Gothel on Nov 27, 2012; 12:02pm
URL: https://forum.jogamp.org/appbundler-jogl-jnilib-dylib-one-jar-confusion-tp4027169p4027245.html
On 11/27/2012 12:44 PM, nyholku [via jogamp] wrote:
> On 26.11.2012 18.25, "gouessej [via jogamp]"
> <[hidden email]> wrote:
>>
>>
>>Yes you should not have the problem you mention but if something goes
>>wrong with launch4j, we won't be able to help you, especially if you use
>>a non standard embedded JVM. It would be less risky to use Java Web Start.
>
>
> Yes, I understand that you might not be able to help me.
>
> Just to clarify:
>
> - Web Start is not acceptable for this application I'm afraid.
>
> - I'm not planning to use a non standard JRE.
>
> - I may have to embed a standard JRE to guarantee compatibility
> and behaviour. This seems to imply that it is not possible to
> use a fat jar approach by itself as the JRE cannot reside in
> the fat jar right?
>
> So I may end up using an installer of some kind approach,
> do you have any recommendations in that respect?Hi, sorry - I have missed the whole discussion.
Ok, so we have the following deployment models working:
- JNLP webstart (Applets, Application, ..)
- NApplet (Applet's using our build-in native lib loading)
- Applications using our build-in native lib loading
- Jar-In-Jar
- <https://jogamp.org/bugzilla/show_bug.cgi?id=522#c7>
- <http://jogamp.org/git/?p=gluegen.git;a=commit;h=04391a3f417e10e1b6dafbd8becc63659af633c3>
All the above have the following in common,
the native library of one module (gluegen, jogl) shall reside in a jar file
at the same base URI of the module with the derived 'natives-OS.and.ARCH' name.
Example:
file:///lala/gluegen-rt.jar
file:///lala/gluegen-rt-natives-linux-amd64.jar
file:///lala/jogl-all.jar
file:///lala/jogl-all-natives-linux-amd64.jar
It doesn't matter whether the JAR basename is kept original or is modified,
we have fixed this w/ our maven2 support.
For example, you can also repack all-in-two (gluegen, jogl, your-app):
file:///lala/MyApp.jar
file:///lala/MyApp-natives-linux-amd64.jar
Please note that above examples only name linux-amd64,
but you should add all native JAR files to support all platforms.
IMHO it would suit you best to use above Jar-In-Jar method,
since it will keep the original JogAmp files intact incl. version numbers.
The latter will help producing proper bug reports etc - but whatever floats your boat.
While we _DO_IGNORE_ all products doing some magic like bundling etc,
our described deployment mechanism is as flexible as it can get
and should be easily applied with your model!
~Sven
URL: https://forum.jogamp.org/appbundler-jogl-jnilib-dylib-one-jar-confusion-tp4027169p4027245.html
On 11/27/2012 12:44 PM, nyholku [via jogamp] wrote:
> On 26.11.2012 18.25, "gouessej [via jogamp]"
> <[hidden email]> wrote:
>>
>>
>>Yes you should not have the problem you mention but if something goes
>>wrong with launch4j, we won't be able to help you, especially if you use
>>a non standard embedded JVM. It would be less risky to use Java Web Start.
>
>
> Yes, I understand that you might not be able to help me.
>
> Just to clarify:
>
> - Web Start is not acceptable for this application I'm afraid.
>
> - I'm not planning to use a non standard JRE.
>
> - I may have to embed a standard JRE to guarantee compatibility
> and behaviour. This seems to imply that it is not possible to
> use a fat jar approach by itself as the JRE cannot reside in
> the fat jar right?
>
> So I may end up using an installer of some kind approach,
> do you have any recommendations in that respect?
Ok, so we have the following deployment models working:
- JNLP webstart (Applets, Application, ..)
- NApplet (Applet's using our build-in native lib loading)
- Applications using our build-in native lib loading
- Jar-In-Jar
- <https://jogamp.org/bugzilla/show_bug.cgi?id=522#c7>
- <http://jogamp.org/git/?p=gluegen.git;a=commit;h=04391a3f417e10e1b6dafbd8becc63659af633c3>
All the above have the following in common,
the native library of one module (gluegen, jogl) shall reside in a jar file
at the same base URI of the module with the derived 'natives-OS.and.ARCH' name.
Example:
file:///lala/gluegen-rt.jar
file:///lala/gluegen-rt-natives-linux-amd64.jar
file:///lala/jogl-all.jar
file:///lala/jogl-all-natives-linux-amd64.jar
It doesn't matter whether the JAR basename is kept original or is modified,
we have fixed this w/ our maven2 support.
For example, you can also repack all-in-two (gluegen, jogl, your-app):
file:///lala/MyApp.jar
file:///lala/MyApp-natives-linux-amd64.jar
Please note that above examples only name linux-amd64,
but you should add all native JAR files to support all platforms.
IMHO it would suit you best to use above Jar-In-Jar method,
since it will keep the original JogAmp files intact incl. version numbers.
The latter will help producing proper bug reports etc - but whatever floats your boat.
While we _DO_IGNORE_ all products doing some magic like bundling etc,
our described deployment mechanism is as flexible as it can get
and should be easily applied with your model!
~Sven
signature.asc (909 bytes) | Free forum by Nabble | Edit this page |