Problem with GLProfile and jogl2-rc2

>
> Hello,
>
> It seems jogl2 have some problem to load profile on my computer, all profile
> equal FALSE :(
> I'm using the getDefaut() method of GLProfile in my program ..
>
> My version of librairies is rc2 :
> http://jogamp.org/deployment/archive/rc/v2.0-rc2/archive/
>
> I load this native library file :
> libgluegen-rt.so
> libjogl_desktop.so
> libjogl_es1.so
> libjogl_es2.so
> libnativewindow_awt.so
> libnativewindow_x11.so
> libnewt.so
>
> My system is :
> Ubuntu 11.10
> i7 cpu
> Quadro FX 2800M 3.3.0 NVIDIA 280.13
>

>
> Info: XInitThreads() called for concurrent Thread support
> Exception in thread "main" javax.media.opengl.GLException: No profile
> available: [GL4bc, GL3bc, GL2, GL2GL3, GL4, GL3, GL2ES2, GLES2, GL2ES1,
> GLES1], GLAvailability[Native[GL4bc false, GL4 false, GL3bc false, GL3
> false, GL2 false, GL2ES1 false, GLES1 false, GL2ES2 false, GLES2 false],
> Profiles[, default null]]
> at
> javax.media.opengl.GLProfile.initProfilesForDefaultDevices(GLProfile.java:1283)
> at javax.media.opengl.GLProfile.access$000(GLProfile.java:71)
> at javax.media.opengl.GLProfile$1.run(GLProfile.java:117)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.media.opengl.GLProfile.initSingleton(GLProfile.java:115)
> at javax.media.opengl.GLProfile.validateInitialization(GLProfile.java:1428)
> at javax.media.opengl.GLProfile.getProfileMap(GLProfile.java:1580)
> at javax.media.opengl.GLProfile.get(GLProfile.java:623)
> at javax.media.opengl.GLProfile.getDefault(GLProfile.java:480)
> at javax.media.opengl.GLProfile.getDefault(GLProfile.java:486)
> 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:94)
> at fr.iscpif.loadCsvData.testGraphique.main(testGraphique.scala)
>
>
> Thanks for your help :)
> SR.
>
> _______________________________________________
> 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-tp3447491p3447491.html
> To start a new topic under jogl, email [hidden email]
> To unsubscribe from jogl, visit
health & wealth
mailto:[hidden email] ; http://jausoft.com
land : +49 (471) 4707742 ; cell: +49 (151) 28145941
Timezone CET: PST+9, EST+6, UTC+1

>
> Thanks for your great answer :)
>
> I explain my point of view for custom loader.
> We use maven to deploy project, and we don't want to add all the jogl
> jar file for all platform on the maven pom project file.
> So we develop a wrapper for jogl 1.x which block initial library
> loading, and load only the good .so for the current architecture of user :
>
> https://forge.iscpif.fr/projects/vizutils/repository/revisions/master/changes/jogl/src/main/java/fr/iscpif/jogl/JOGLWrapper.java
>
> For example, i want to use a project with jogl1, like jzx3d or other.
> I create a maven pom.xml with the wrapper in dependency, and i add on
> the init() method of this project my wrapper.init() method which block
> and load the good library file.
>
> So i a first draft, i try to make the same code for jogl2.x, but it's
> not the same mecanism ... and as you see with my error i have some
> problem to load the library ...
> And your explanation is good, so i don't know is this idea of generic
> wrapper is good in reality ... :-/

> On Monday, October 24, 2011 02:40:06 PM reyman [via jogamp] wrote:
> Within gluegen's native jar loading mechanism and within our build/deployment
> we use the same naming convention for native JARs 'os_and_arch':
>
> http://jogamp.org/jogl/doc/deployment/JOGL-DEPLOYMENT.html#NativeJARFileNameConvention
>
> http://jogamp.org/git/?p=gluegen.git;a=blobdiff;f=src/java/com/jogamp/common/os/Platform.java;h=78daf4c3639a145bd9ec39c530e6b199478334c9;hp=a1e8bd5a873402220a152d24846a36d570dab047;hb=69d537e4f9e6e5d206719723094ea192ab51ef43;hpb=0711792f00e462e340e0d3731dfe71b0e8ec6022
>
> >
> > We create a pom.xml for our project with glugen-rt-all.jar and jogl-all.jar,
> > and it's rocks :)
>
> It would be best, if you can provide 'intelligent' pom files,
> utilizing the above mentioned 'os_and_arch' mechanism.
>

>
> Ok, so, to make this possible we need :
>
> (server)
>  > a script which automaticaly get/download the jar : gluegen-rt and jogl +
> all natives
>  > a script which create pom.xml and push on a maven repository all the jar
>
> (client)
> > a pom.xml with architecture description and correct dependency for each
> > arch
>
> A post with description of architecture
> http://stackoverflow.com/questions/1962718/maven-and-the-jogl-library
> http://stackoverflow.com/questions/166895/different-dependencies-for-different-build-profiles-in-maven
>

> On Monday, October 24, 2011 03:52:42 PM reyman [via jogamp] wrote:
>
> >
> > Ok, so, to make this possible we need :
> >
> > (server)
> > > a script which automaticaly get/download the jar : gluegen-rt and
> jogl +
> > all natives
> > > a script which create pom.xml and push on a maven repository all
> the jar
> >
> > (client)
> > > a pom.xml with architecture description and correct dependency for
> each
> > > arch
> >
> > A post with description of architecture
> > http://stackoverflow.com/questions/1962718/maven-and-the-jogl-library
> >
> http://stackoverflow.com/questions/166895/different-dependencies-for-different-build-profiles-in-maven
> >
>
> For 'just' using JOGL via maven/pom-file, IMHO we just need:
> - generate this pom file for each deployment on jogamp (fixed URLs),
> which will
>   - simple referencing the pure-java and native-lib JARs for download
> and use
>
> We can add this pom-file generation in our deployment script (if it
> technically works this way).
> If you provide a good boilerplate for let's say jogamp-next's URL,
> I can drop it in our scripting.
> You could prep the maven dependencies according to our 'os_and_arch'
> naming convention,
> so they result in the same native JAR files/URLs.
>
> Then we may offer pom URLs as we offer our versions as described here
> http://forum.jogamp.org/New-Deployment-FHS-Filesystem-Hierarchy-Standard-td3334675.html
> for example:
> http://jogamp.org/deployment/jogamp-current/
> http://jogamp.org/deployment/jogamp-next/
> http://jogamp.org/deployment/v2.0-rc3/
>
> If you can provide a 'pom dependency family' for the base URL:
> http://jogamp.org/deployment/archive/master/gluegen_424-joal_228-jogl_526-jocl_455/
>   (due to it's native jar file utilization)
>
> I could continue maintaining it from there w/ your help / validation.
>
> > But there is another solution, imho more complicated. We get the
> build.xml
> > from jogl / gluegen and rewrite it from scratch for maven. I
> download the
> > jogl sources to see, and it seems this is a lot of work for one
> personn :s
>
> I am not a maven expert, but IMHO it's should be possible to kick off
> an ant-based build.
> However, I would not like to introduce _and_ maintain another build
> system.
> Indeed this is not just a huge effort, but also contraproductive IMHO,
> unless we switch over to a maven/pom build system completly.
> The latter is currently really not within our plan,
> so if anybody does it .. she should do it for *all* jogamp modules
> and proove it's great and working properly.
>
> ~Sven
>