Problem with GLProfile and jogl2-rc2

Le jeu. 27 oct. 2011 12:03:19 CEST, rey sebastien a écrit :
I mavenize JZY3D with jog and gluegen remote dependency, and i try to
use it with a custom script.
The custom script is ok, i'm sure because it's work with jogl1 + old
version of jzxy3d

I have this error when i try to load graphic display, and the
dependency download on remote nexus server works ,
so it seems jzxy3d doesn't use the native loader in rc4.

Do you have a piece of code, or sample on how to load the jni ?

Thanks a lot :)

My error :
java.util.zip.ZipException: error in opening zip file
        at java.util.zip.ZipFile.open(Native Method)
        at java.util.zip.ZipFile.<init>(ZipFile.java:127)
        at java.util.jar.JarFile.<init>(JarFile.java:135)
        at java.util.jar.JarFile.<init>(JarFile.java:72)
        at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:72)
        at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:48)
        at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:55)
        at
sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:104)
        at
sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:71)
        at com.jogamp.common.util.JarUtil.getJarFile(JarUtil.java:153)
        at com.jogamp.common.os.Platform$3.run(Platform.java:308)
        at java.security.AccessController.doPrivileged(Native Method)
        at com.jogamp.common.os.Platform.loadGlueGenRTImpl(Platform.java:299)
        at com.jogamp.common.os.Platform.<clinit>(Platform.java:208)
        at javax.media.opengl.GLProfile.<clinit>(GLProfile.java:1155)
        at org.jzy3d.global.Settings.<init>(Settings.java:53)
        at org.jzy3d.global.Settings.getInstance(Settings.java:18)
        at org.jzy3d.chart.Chart.<init>(Chart.java:52)
        at org.jzy3d.chart.Chart.<init>(Chart.java:40)
        at fr.iscpif.loadCsvData.testGraphique$.main(testGraphique.scala:95)
        at fr.iscpif.loadCsvData.testGraphique.main(testGraphique.scala)
Exception in thread "main" java.lang.UnsatisfiedLinkError: no
gluegen-rt in java.library.path
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1738)
        at java.lang.Runtime.loadLibrary0(Runtime.java:823)
        at java.lang.System.loadLibrary(System.java:1028)
        at
com.jogamp.common.jvm.JNILibLoaderBase.loadLibraryInternal(JNILibLoaderBase.java:310)
        at
com.jogamp.common.jvm.JNILibLoaderBase.access$000(JNILibLoaderBase.java:57)
        at
com.jogamp.common.jvm.JNILibLoaderBase$DefaultAction.loadLibrary(JNILibLoaderBase.java:87)
        at
com.jogamp.common.jvm.JNILibLoaderBase.loadLibrary(JNILibLoaderBase.java:207)
        at
com.jogamp.common.os.DynamicLibraryBundle$GlueJNILibLoader.loadLibrary(DynamicLibraryBundle.java:344)
        at com.jogamp.common.os.Platform$3.run(Platform.java:314)
        at java.security.AccessController.doPrivileged(Native Method)
        at com.jogamp.common.os.Platform.loadGlueGenRTImpl(Platform.java:299)
        at com.jogamp.common.os.Platform.<clinit>(Platform.java:208)
        at javax.media.opengl.GLProfile.<clinit>(GLProfile.java:1155)
        at org.jzy3d.global.Settings.<init>(Settings.java:53)
        at org.jzy3d.global.Settings.getInstance(Settings.java:18)
        at org.jzy3d.chart.Chart.<init>(Chart.java:52)
        at org.jzy3d.chart.Chart.<init>(Chart.java:40)
        at fr.iscpif.loadCsvData.testGraphique$.main(testGraphique.scala:95)
        at fr.iscpif.loadCsvData.testGraphique.main(testGraphique.scala)

Le 24/10/2011 21:13, Sven Gothel [via jogamp] a écrit :

On Monday, October 24, 2011 08:51:41 PM reyman [via jogamp] wrote:

> >
> > Reyman, will I see test maven files (gluegen-rt/jogl/..) from you then ?
> >
> > ~Sven
> >
> >
> >
>
> Yes, i can try to implement this or test the implementation of other
> person,
> and if we need i have an account on a nexus server to test,  
>
> Do you have an idea/ preference for the macro script implementation ?
> I have some competence in python and java/scala.
> But the java language is perhaps the best here to do this ?
>

Thank you!

I thought you could just generate a static 'demo' maven/pom file
which would work w/
  http://jogamp.org/deployment/archive/master/gluegen_424-joal_228-jogl_526-jocl_455/
(so we may can test it w/ a simple test application).

Then I could replace the URLs with macros/tags, like this JNLP file:
  http://jogamp.org/git/?p=jogl.git;a=blob;f=jnlp-files/jogl-all-awt.jnlp;hb=HEAD
and add these pom templates to the repo.

The final deployment script:
  https://jogamp.org/chuck/view/fwd/job/jogamp-scripting-promote-last-builds-master/
  http://jogamp.org/git/?p=jogamp-scripting.git;a=blob;f=jenkins-builds/promote-latest-builds.sh;hb=HEAD
will resolve the URLs and deploy it w/ the other files.

(It's a pure dumb bash script)

I kick of deployment manually when we think we need it,
it produces the above gluege_424-joal_228.. URL.
Later, when we like to promote this 'release', we sign it manually
and have eg. another official release, like RC3.

Would that work for us ?

~Sven

---

If you reply to this email, your message will be added to the discussion below:

http://forum.jogamp.org/Problem-with-GLProfile-and-jogl2-rc2-tp3447491p3449187.html

To unsubscribe from Problem with GLProfile and jogl2-rc2, click here.

Perhaps the error/mistake is here ?

http://jogamp.org/git/?p=jogl.git;a=commitdiff;h=ac358bd66878e63a370377d4c7f625ec5b1b9e31

You call for jni loader the line :
+                                if( jarName.startsWith("jogl.all") ) {
+                                    // all-in-one variant
+                                    JNILibLoaderBase.addNativeJarLibs(c, "jogl-all");
+                                }

why here this is not    JNILibLoaderBase.addNativeJarLibs(c, "jogl.all");
?
Thanks for help :)
Seb

Hi

Sven is right, he uses "jogl-all" as a prefix for JARs containing native libraries. If some users don't want to use the automatic loading of those JARs, they have to set jogamp.gluegen.UseTempJarCache to false.

Ok it works fine for me :)

Le jeu. 27 oct. 2011 19:10:14 CEST, gouessej [via jogamp] a écrit :
I read on a post on this forum you had the same problem with
"java.util.zip.ZipException: error in opening zip file "
How do you resolve this problem ?
And in your program how do you initialize the start of opengl ? Because
in my case, it seem jzxy3d not call the good method to load the jni
file ?

Le 27/10/2011 19:10, gouessej [via jogamp] a écrit :

Ok it works fine for me :)

Julien Gouesse
http://tuer.sourceforge.net
http://gouessej.wordpress.com

---

If you reply to this email, your message will be added to the discussion below:

http://forum.jogamp.org/Problem-with-GLProfile-and-jogl2-rc2-tp3447491p3458366.html

To unsubscribe from Problem with GLProfile and jogl2-rc2, click here.

I don't understand one thing with jogl-all or jogl.all :

I deploy a jar like this "jogl.jar-version", and the artifact id to load is :
        <dependency>
        <groupId>org.jogamp.jogl</groupId>
        <artifactId>jogl.all</artifactId>
        <version>2.0-b526-20111018</version>   
        </dependency>

But when i launch a project which use jzxy3d, if the loader try to load a jar like "jogl-all-version",
this is a problem, because only jogl.all-version exist on maven repository.
Bizarre Bizarre ...

I resolved this problem by setting jogamp.gluegen.UseTempJarCache to false but it was not the best solution. I found a better fix, I put all JARs containing the native libraries into the class path and then it worked.

I did this to use your thing in Maven, I put this in the parent POM file of Ardor3D and in the sub-project containing my own JOGL 2.0 renderer:
<repository>
<id>maven.iscpif.fr</id>
<name>ISCPIF repository</name>
<url>http://maven.iscpif.fr/thirdparty/</url>
</repository>

<dependency>
<groupId>org.jogamp.jogl</groupId>
<artifactId>jogl.all</artifactId>
<version>2.0-b526-20111018</version>
</dependency>
<dependency>
<groupId>org.jogamp.gluegen</groupId>
<artifactId>gluegen-rt</artifactId>
<version>2.0-b424-20111018</version>
</dependency>

I use a kind of mix between Ant, Maven and Eclipse builder to build my game.

Edit.: I understand your problem. The automatic loading does not find the JAR because it is not called jogl.all.jar. Is there a way of forcing Maven not to put the version into the name of the JAR? Another solution would consist in modifying Maven script or using an Ant script to rename the JARs or you could use a special classloader able to use a regular expression to find the JARs, for example gluegen-rt*.jar instead of gluegen-rt-2.0-b424-20111018.jar.

On Thursday, October 27, 2011 11:20:17 PM gouessej [via jogamp] wrote:
>
> I resolved this problem by setting jogamp.gluegen.UseTempJarCache to false
> but it was not the best solution. I found a better fix, I put all JARs
> containing the native libraries into the class path and then it worked.
>

As I have described in a prev. email and blog,
it should not be required to put the native JARs in the CLASSPATH!
Our native JAR loading mechanism picks them up from the 'URL' (file, http, ..)
where it's '-all' pure java counterpart is located.

After checking OS X Lion Applet's .. I will check the maven stuff,
so we can provide the pom files properly for the next round.

~Sven

I have just found this to resolve Reyman's problem:
http://kthoms.wordpress.com/2009/10/13/how-to-register-a-custom-maven-repository-layout/

Using a custom layout in order to exclude package id and version id from the name of the JARs would solve his problem.

Thanks for this piece of information. I just have to take care to put all JARs containing native libraries into the same directories than its pure Java counterparts, it is even more simple than I thought :)

Yes, this is a good trail i think,

Hum it seems it's impossible to change the name of jar in the repository :

See my question here :
http://stackoverflow.com/questions/7927762/change-name-of-dependency-jar-before-upload-on-remote-repository

And the answer refer to this discussion :
http://stackoverflow.com/questions/2364363/how-to-stop-maven-renaming-installed-jars/2364493#2364493

Therefore, maybe have a look at Maven Assembly Plugin.

I will have to find a solution on my side to copy the JAR files from Maven cache to another directory inside the Eclipse project so that it does not complain about missing JARs.

Edit.: This tutorial (in French) answers to my question:
http://matthieu-lux.developpez.com/tutoriels/java/maven/?page=eclipse

Edit.2: Maybe the automatic loader could be modified so that it looks for the Mavenized JARs as it knows its own version of JOGL. Then, installing a project as a Maven project in Eclipse would be quite simple. com.jogamp.common.util.JogampVersion knows the implementation branch and the implementation commit, it should compute the name of a Mavenized JAR and look at it if jogl.all.jar is not found.

Yes i think the idea of gouessej is the best,
because we can change the name of dependance into the jar with maven-assemby and dependency-set (http://maven-guide-fr.erwan-alliaume.com/maven-reference-fr/site/reference/assemblies-sect-output-algorithm.html) , but user of jogl need to know how create an assembly.xml, and this is not easy ...

Change the automatic loader to auto-detect the version of jar in the final jar, if it's possible, is a good idea :)

One last problem: I don't know if Eclipse behaves correctly when a project is imported from SVN as a Maven project (by using M2Eclipse). Does it handle the dependencies as JARs in the class path? If not, the developers will see a lot of warnings, Eclipse builder will believe that the JARs are missing even though Maven will be able to make the build... except if you manually copy the JARs into the workspace :( Using Maven Eclipse plugin is not fine because it ties the project with Eclipse whereas there are some other IDEs...

Le ven. 28 oct. 2011 17:41:25 CEST, gouessej [via jogamp] a écrit :
If you create a maven with a plugin assembly, you have the dependencies
in the jar ( mvn assembly:assembly on cmd line)

<build>
    <plugins>
        <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-assembly-plugin</artifactId>
    <version>2.2</version>
    <configuration>
      <descriptorRefs>
        <descriptorRef>jar-with-dependencies</descriptorRef>
      </descriptorRefs>
    </configuration>
    <executions>
      <execution>
        <phase>package</phase>
        <goals>
          <goal>single</goal>
        </goals>
      </execution>
    </executions>
  </plugin>
    </plugins>
</build>

This code snippet resolve your problem gouessej or this is another problem ?

On Wednesday, October 26, 2011 11:24:06 PM reyman [via jogamp] wrote:
>
> I make some BIG correction on script , and i take the time to test it on my
> machine, compilation it's now ok for me.
>
> Other person test on a real project ?
>
> The url on github is the same : git://github.com/reyman/scriptJogamp.git

Sorry .. that I have somehow have lost this conversation ..

Please help me w/ integrating your solution,
ie .. what shall I add in our scripting. The stuff from the above URL ?
In the end .. I like to produce the required pom files via
our jogamp-scripting deployment scripts .. as you know.

Sorry for being late, but I was off the whole weekend
and try to catch up with things ..

Since I am also busy w/ the OSX Applet stuff and you guys are
now the experts about maven here .. I guess it would be best
to give me clear directions about your maven solution.

- Which files to produce
- .. etc ..

Thank you so much.

~Sven

No problem, i'm ready and ok to integrate the generation of the pom in your deploiement script :)

But at this time the simple example of jar we deploy on maven.iscpif.Fr doesn't work because the jar in the archive contain the both the version and the arch in his name, for example we have jogl-natives-amd64-2.xx.xx.jar

The loader you create doesn't find the jar in our assembly jar, so we cannot continue without your help on this problem :)

Gouessej suggest you modify the loader of jar; like this :
" Maybe the automatic loader could be modified so that it looks for the Mavenized JARs as it knows its own version of JOGL. Then, installing a project as a Maven project in Eclipse would be quite simple. com.jogamp.common.util.JogampVersion knows the implementation branch and the implementation commit, it should compute the name of a Mavenized JAR and look at it if jogl.all.jar is not found."

On Tuesday, November 01, 2011 04:21:24 PM reyman [via jogamp] wrote:
>
> No problem, i'm ready and ok to integrate the generation of the pom in your
> deploiement script :)
>
> But at this time the simple example of jar we deploy on maven.iscpif.Fr
> doesn't work because the jar in the archive contain the both the version and
> the arch in his name, for example we have jogl-natives-amd64-2.xx.xx.jar

the version can be encoded in the URL,
ie where we drop/deploy the JARs on jogamp.org (or wherever).

>
> The loader you create doesn't find the jar in our assembly jar, so we cannot
> continue without your help on this problem :)

ofc I like to to change as little as possible in our current deployment scheme,
however .. if it's required.

Please point me to the latest version of your desired maven files
you like to see integrated.
This way I can understand the issue a bit better and maybe we can find a compromise.
Looks like there are 'runtime' maven dependencies/issues besides the 'compile time'
dependencies ?

Thank you.

~Sven

>
> Gouessej suggest you modify the loader of jar; like this :
> " Maybe the automatic loader could be modified so that it looks for the
> Mavenized JARs as it knows its own version of JOGL. Then, installing a
> project as a Maven project in Eclipse would be quite simple.
> com.jogamp.common.util.JogampVersion knows the implementation branch and the
> implementation commit, it should compute the name of a Mavenized JAR and
> look at it if jogl.all.jar is not found."
>

--