Using JOGL in Eclipse

Hi,

I'm using both JOGL and Eclipse for some years for my desktop application project. Up to now, I have manually extracted all jar files and native files (.dll, .so, ...) and created my own JOGL user library in Eclipse. This worked quite fine, but requires some stupid work.

Now I'm wondering if it is possible to use the jogl-all-awt.jnlp and gluegen-rt.jnlp in Eclipse directly. I downloaded the required jar files (jogl.all.jar, gluegen-rt-natives-*.jar, gluegen-rt.jar, gluegen-rt-natives-*.jar), removed the URLs and the update check from the JNLP file - and I'm stuck: I can not find a way to tell Eclipse to use the JNLP file "in the classpath".

Maybe this is the wrong way...  Can you tell me the easiest way to use JOGL in Eclipse, for all platforms? Maybe the answer is also interesting for the deployment wiki page. 

Thanks

Andi

To sum it up, what I want to avoid is

1) having an own runtime configuration for each platform (I'm developing on Windows 64+32, Linux 32 and Mac OS X)
2) having an own starter (start.sh/.bat) for each platform (e.g. "start-win32.bat" vs. "start-win64.bat", I want a single "start.bat")

I already though about setting the java.library.path in the Java code, but maybe there is a much nicer solution?

Hi Andi,

One solution (which I describe at http://wadeawalker.wordpress.com/2010/10/24/tutorial-creating-native-binary-executables-for-multi-platform-java-apps-with-opengl-and-eclipse-rcp/) is to write your desktop app as an Eclipse RCP app. This takes care of the multi-platform aspect, and gives you a native binary for each platform rather than a batch file.

If you really want only one batch file, you'd have to write it in some language that works on all your platforms somehow, then set the java.library.path inside it, then invoke your program with "java -jar". You can't set java.library.path from inside your Java program, because they're read-only

Maybe Launch4j is what u are searching for ?

Launch4j or JEStart (the launcher I've written some years ago) are a nice thing, but they do not tackle the original problem.

What I am looking for is an automatic way for the JVM to find the right native libs. Currently, I can for example not just use the same java.library.path for both versions of windows (32bit and 64bit), because the DLL names collide and are incompatible. But I want a single windows distribution for my program.

You are right that a launcher like Launch4J or JEStart could determine the right version and set the correct java.library.path. However, I see that the Java Platform (Webstart) is already able to do that automatically, as you can see if you have a look at the JNLP files! I was wondering if I can add those JNLP files "to my classpath" so that the JVM finds the right native libraries automatically.

Another advantage is, that I would not need a separate Eclipse runtime configuration for each platform...

Any ideas? If not, I can do it as proposed (thanks for all your tips!), however it feels like a workaround.

Hmm, I guess if you didn't mind deploying your app as "local" Java Web Start (i.e. launched from a JNLP on the local disk, example at http://jogamp.org/wiki/index.php/Using_JOGL_in_Java_Web_Start), you could create your project in Eclipse, point Eclipse at only one set of native libs (the ones for your development platform), and develop in Eclipse as normal.

Then to deploy, you'd use an Ant script to JAR up your project and put it in a dir with the JNLP files. You'd still have to write a cross-platform launch script to call "javaws MyApp.jnlp", though.

>Currently, I can for example not just use the same java.library.path
>for both versions of windows (32bit and 64bit), because the DLL
>names collide and are incompatible. But I want a single windows
>distribution for my program.

Hmm I always thought that it is impossible to intermix 32+64bit dll's under windows. So u need to start a different JVM for 32/64bit anyway, wich in the end leads again to some kind of "pre"-launcher/dropper choosing the right JVM for u.

>Another advantage is, that I would not need a separate Eclipse runtime configuration for each platform...
>Any ideas? If not, I can do it as proposed (thanks for all your tips!), however it feels like a workaround.

Yep an all-in-one multiplatform distribution would be really great, but I've never seen such a thing . All cross-platfrom technologies like Adobe AIR oder Java work that way, using a generic development approach and then deploying mutliple platform specific runtime versions. And yes I totally agree it not only "feels like a workaround" it actually is

Hi

Try to use M2Eclipse and our very recent Maven repository, it will solve your problem.