>
>
>    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=04391a3f417e10e1b6dafbd8b
>ecc63659af633c3>
>
>
>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) Download Attachment
><http://forum.jogamp.org/attachment/4027245/0/signature.asc>
>
>    
>    
>    
>    
>    
>    ________________________________________
>    
>        If you reply to this email, your message will be added to the
>discussion below:
>        
>http://forum.jogamp.org/appbundler-jogl-jnilib-dylib-one-jar-confusion-tp4
>027169p4027245.html
>    
>    
>        
>        To unsubscribe from appbundler jogl jnilib dylib one-jar
>confusion, click here
><http://forum.jogamp.org/template/NamlServlet.jtp?macro=unsubscribe_by_cod
>e&node=4027169&code=a3VzdGFhLm55aG9sbUBwbGFubWVjYS5jb218NDAyNzE2OXwtMTgxMD
>M2ODU3Ng==>.
>        NAML
><http://forum.jogamp.org/template/NamlServlet.jtp?macro=macro_viewer&id=in
>stant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespac
>e-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNa
>mespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_email
>s%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>