how can I build jogl 2.3.3 and when is it due for release

I am working with the vZome application from http://vzome.com. It currently uses jogl 2.3.2. It runs fine on my Windows 10 computer, but when I run it in Ubunto 17.10 inside VirtualBox on the same hardware. I get an error similar to the one described at http://forum.jogamp.org/problem-using-jogl-2-3-2-on-linux-td4038557.html and http://forum.jogamp.org/Mesa-17-2-0-renderer-driver-name-change-error-causes-GLProfile-not-mapped-initialization-error-td4038176.html. The specific Mesa version shown in my case is 17.2.8.

I think that the bug fix described in https://jogamp.org/bugzilla/show_bug.cgi?id=1357 should resolve my issue so I'd like to know how to get a version of jogl that includes that fix so I can try it. I think that will be jogamp 2.3.3. Ideallly, I'd like to be able to pull the most recent successful build from a maven repo, but I don't know if that option is even available.

I considered trying to build it myself from sources as described at http://jogamp.org/jogl/doc/HowToBuild.html, but the very first steps (git clone) failed since apparently the URL listed in the instructions is incorrect or out of service.

I'd like to know when 2.3.3 (or whatever release fixes bug 1357) might be available and how to get on a mailing list to know as soon as it's released. In the mean time, I'd be willing to try building it myself if I had some good instructions. I'd even be willing to update the HowToBuild wiki page with the updated instructions if that's helpful.

Any ideas?
Thanks,
David

Hey

Have you read my comment?
http://forum.jogamp.org/Mesa-17-2-0-renderer-driver-name-change-error-causes-GLProfile-not-mapped-initialization-error-tp4038176p4038648.html

No the instructions are correct. What didn't work for you?

I can find some time to provide a patched version only with the bug fix of the bug 1357.

Thanks Julien, I'd be willing to test a patched jar file for you if that helps expedite the testing and release process, but I'm pretty sure that we'd prefer to wait for the next official release rather than distribute a patched jar with our application.

The problem I am having with building it myself from sources is downloading the actual code. Here's what I get:

C:\Users\David\Documents\GitHub\jogamp>git clone --recurse-submodules git://jogamp.org/srv/scm/gluegen.git gluegen
Cloning into 'gluegen'...
fatal: unable to connect to jogamp.org:
jogamp.org[0: 2a01:4f8:192:1164::2]: errno=Invalid argument
jogamp.org[1: 144.76.84.101]: errno=Invalid argument


C:\Users\David\Documents\GitHub\jogamp>git clone --recurse-submodules git://jogamp.org/srv/scm/jogl.git jogl
Cloning into 'jogl'...
fatal: unable to connect to jogamp.org:
jogamp.org[0: 2a01:4f8:192:1164::2]: errno=Invalid argument
jogamp.org[1: 144.76.84.101]: errno=Invalid argument

I've just provided the patched class file here:
https://jogamp.org/bugzilla/show_bug.cgi?id=1357#c11

I'll provide a patched JAR in less than 12 hours.

There is probably a problem of networks or authorization as I succeeded in committing some source code a few days ago.

I spent several hours in finding a decent tool to edit the bytecode...

Sorry, I'll provide the fat JAR later, probably tomorrow.

David wrote

C:\Users\David\Documents\GitHub\jogamp>git clone --recurse-submodules git://jogamp.org/srv/scm/jogl.git jogl
Cloning into 'jogl'...
fatal: unable to connect to jogamp.org:
jogamp.org[0: 2a01:4f8:192:1164::2]: errno=Invalid argument
jogamp.org[1: 144.76.84.101]: errno=Invalid argument

For what it's worth I just tried and had no problems (OSX):

 git clone git://jogamp.org/srv/scm/jogl.git jogl
Cloning into 'jogl'...
remote: Counting objects: 102652, done.

Enjoy, this JAR contains JOGL 2.3.2 + the bug fix of the bug 1357:
https://sourceforge.net/p/tuer/code/1319/tree//pre_beta/lib/jogamp/jogamp-fat.jar?format=raw

Sven will provide something a lot cleaner later.

Thanks @jmaasing

I had an idea that the git protocol may be blocked by default in my Windows firewall, so I tried replacing git:// with https:// in the two commands and I was able to clone both of them locally. It might be worthwhile to update the instructions at http://jogamp.org/jogl/doc/HowToBuild.html to specify https instead of git so that others won't run into this.

At some point, I may mess with the Windows firewall settings and see if I can determine if that's really the problem.

I also came across another git configuration option that I may try, which helps with if the git protocol is blocked by a local firewall. It's described at https://bredland.wordpress.com/2015/09/30/git-protocol-tcp-9418-blocked-by-firewall/. I'll try that someday too. Basically, it simply says to run the following command:

    git config --global url."https://".insteadOf git://

In the mean time, since Julien has provided a JAR containing JOGL 2.3.2 + the bug fix of the bug 1357, I'll just try his for now and post back here whether it works for me or not.

Thanks all.

If it doesn't work, it will mean that your problem was caused by another bug. My fix works and the fat JAR I've just posted works too. Keep in mind that some web browsers wraps JARs into ZIP archives without renaming them, it might break this fat JAR. Use curl or wget to work around this if necessary. Good luck.

After all Julien's work, now I'm not sure how to use the new jogamp-fat.jar file in my situation. I thought that I'd just be able to replace one by the same name distributed with my app with the one Julien provided, but I discovered that my app isn't distributed with jogamp-fat.jar. It includes a bunch of other gluegen and jogl jar files that I suspect are a subset of jogamp-fat.jar as shown in the directory listing below. I tried just dropping the new jogamp-fat.jar in the same folder with all of the other jars and nothing changed when I ran my app. I tried removing all of the jogl files (but not the gluegen files) and having only jogamp-fat.jar in the folder, but that was obviously wrong.  How can I be sure if the new jar file is even being used by my app?

Here's a listing of the related jar files in my app's lib folder. How do I integrate the new jar file?

jogamp-fat.jar contains all necessary Java and native libraries for JogAmp (JOGL, JOAL, JOCL, GlueGen). You need to use jogamp-fat.jar and the JARs of Java3D as it is explained in the official Java3D user's guide I wrote. If you put other JOGL JARs into your classpath, the broken version of GLContextImpl might be loaded. Please rather use Java3D 1.6.0-Final.

My fix works, it has been tested by others, it does what it is expected to do.

gouessej wrote

Sven will provide something a lot cleaner later.

Do you have any idea of timescale on that?  The current state of JOGL is concerning, and having to continually rely on unofficial / patched binaries is far from ideal.

More to the point, is this project dying, or is there things we can do to help give it a shot in the arm?

Thanks, Neil

The project isn't dying. If it were dying, I wouldn't spend my time here. I'm very busy, I have no time to waste and I wouldn't spend more than 3 hours to tinker the bytecode. JogAmp native libraries are difficult to build on all supported platforms, otherwise I would have done it cleanly by myself.

gouessej wrote

The project isn't dying. If it were dying, I wouldn't spend my time here. I'm very busy, I have no time to waste and I wouldn't spend more than 3 hours to tinker the bytecode. JogAmp native libraries are difficult to build on all supported platforms, otherwise I would have done it cleanly by myself.

That wasn't meant as a criticism!  Of you or JOGL.  But also, patched binaries are not a sign of a currently healthy open-source project.  Just asking for a more visible, open and realistic conversation on where things are at, what needs to be done, and how it might happen.

JOGL is a key dependency of my own open-source work - I'd rather not have to put time into migrating to something else, hence being interested if there's things we (wider community) can do to help get things on a healthier footing?

I have access to the sftp server, I just refuse to push something "dirty". Do you have access to some computers under GNU Linux, OS X and Windows?

gouessej wrote

I have access to the sftp server, I just refuse to push something "dirty". Do you have access to some computers under GNU Linux, OS X and Windows?

As a matter of fact, yes, for testing purposes (just hate using them! ;-) ) ... but surely some form of CI builds would be a better option?

Yes, there is already a server for continuous integration using Jenkins. Why not sending an email to Sven in order to explain your fears and to suggest to provide some nightly builds?

gouessej wrote

Yes, there is already a server for continuous integration using Jenkins. Why not sending an email to Sven in order to explain your fears and to suggest to provide some nightly builds?

OK, so why the question about access to Linux, Mac, Win then?  Nightly builds would be great, and surely a better option than the patched JAR?  

It's in case we don't have a reply in a timely manner, in order to build it ourselves.