Problem with GLProfile and jogl2-rc2

classic Classic list List threaded Threaded
64 messages Options
1234
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Problem with GLProfile and jogl2-rc2

reyman
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with GLProfile and jogl2-rc2

gouessej
Administrator
This post was updated on .
Hi

I use the same hardware but on Linux Cent OS 5.3 without problem (NVIDIA Quadro FX 3600). Several people reported some regressions when switching from Ubuntu 11.04 to Ubuntu 11.10. We have not yet found the root cause of this bug. Please try to use the latest dev build or at least the RC3 or 4 instead of the RC2. Maybe write a bug report. Best regards.

Edit.: You don't need to load es1 and es2 in desktop environments.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with GLProfile and jogl2-rc2

Sven Gothel
Administrator
In reply to this post by reyman
On Monday, October 24, 2011 10:45:46 AM reyman [via jogamp] wrote:

>
> 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
>

The above config (OS, cpu and GPU) is validated, ie it works.

Please follow the FAQ 'Bugreports & Testing' thoroughly
  http://jogamp.org/wiki/index.php/Jogl_FAQ#Bugreports_.26_Testing

What would be nice to have is:
  http://jogamp.org/wiki/index.php/Jogl_FAQ#Runtime_Version_Check

and if you could run the version check w/ the debug flags enabled,
that would be of help as well:
  http://jogamp.org/wiki/index.php/Jogl_FAQ#Detailed_Bug_Information

ie: edit the etc/tests.sh script and 'add/enable' the line:
+++
D_ARGS="-Djogamp.debug=all -Dnativewindow.debug=all -Djogl.debug=all -Dnewt.debug=all"
+++

then .. send us the test.log file please.

Thank you, Sven

>
> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with GLProfile and jogl2-rc2

reyman

I try on another ubuntu system, the previous ubuntu 10.10, and same error.

Here the log on my system :
http://pastebin.com/EEndqbQL

Thanks for your help :)
Best regards;
SR
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with GLProfile and jogl2-rc2

Sven Gothel
Administrator
In reply to this post by gouessej
On Monday, October 24, 2011 10:54:07 AM gouessej [via jogamp] wrote:
>
> Hi
>
> I use the same hardware but on Linux Cent OS 5.3 without problem (NVIDIA
> Quadro FX 3600). Several people reported some regressions when switching
> from Ubuntu 11.04 to Ubuntu 11.10. We have not yet found the root cause of
> this bug.

Nope, I could run our unit tests on ubuntu 11.10 w/o regressions.

~Sven
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with GLProfile and jogl2-rc2

Sven Gothel
Administrator
In reply to this post by reyman
On Monday, October 24, 2011 11:25:07 AM reyman [via jogamp] wrote:
>
> I try on another ubuntu system, the previous ubuntu 10.10, and same error.

Yup, Ubuntu 11.10 is not an issue (passed all unit tests).

>
> Here the log on my system :
> http://pastebin.com/EEndqbQL

Thank you.

line 568:
X11GraphicsDevice[type X11, connection :0]: GLAvailability[Native[GL4bc false, GL4 false, GL3bc true[3.3 (compatibility profile, any, new)], GL3 true[3.3 (core profile, any, new)], GL2 true[3.0 (compatibility profile, any, new)], GL2ES1 true, GLES1 false, GL2ES2 true, GLES2 false], Profiles[GLProfile[GL2ES2/GL2], GLProfile[GL2ES1/GL2], GLProfile[GL2/GL2], GLProfile[GL3/GL3], GLProfile[GL3bc/GL3bc], GLProfile[GL2GL3/GL2], GLProfile[GL3bc/GL3bc], , default GLProfile[GL3bc/GL3bc]]]

so all looks great!

looks like you launch your application in a way where it doesn't pick up
the native libraries of jogl/gluegen ?

pls try to run your application/test w/ the debug flags:
+++
D_ARGS="-Djogamp.debug=all -Dnativewindow.debug=all -Djogl.debug=all -Dnewt.debug=all"
+++

You can try the latest pre rc4 binaries, eg:
  http://jogamp.org/deployment/archive/master/gluegen_424-joal_228-jogl_526-jocl_455/archive/
where the native libraries are loaded from the native jar files (same location as the java jar files).

>
> Thanks for your help :)

Thank you.

~Sven

> Best regards;
> SR
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with GLProfile and jogl2-rc2

reyman
Here the result, it seems i have some problems to load the library :s
http://pastebin.com/A7Jp7qeN
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with GLProfile and jogl2-rc2

Sven Gothel
Administrator
On Monday, October 24, 2011 11:55:55 AM reyman [via jogamp] wrote:
>
> Here the result, it seems i have some problems to load the library :s
> http://pastebin.com/A7Jp7qeN
>

Assuming you have set '-Djogamp.debug=all ..',
there is no message: 'JNILibLoaderBase ..'

GLProfile also states no desktop GL available, meaning no jogl JNI libs.

If you use RC2, you need to add the libs native library path to LD_LIBRARY_PATH,
eg: "export LD_LIBRARY_PATH=/JOGL/gluegen_and_jogl/lib:$LD_LIBRARY_PATH"

Again, you may like to use the pre RC4, where all of this is no more required.
RC4 will come out this week anyways.

~Sven
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with GLProfile and jogl2-rc2

reyman
Thanks, so i try the pre-RC4

Another question, i want my application ready for different platform, so i use a custom loader like this :
https://github.com/Jotschi/jogl2-example

Do you have an idea of the modification i change to use this with RC4 ?
Loader is very different ?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with GLProfile and jogl2-rc2

gouessej
Administrator
Hi

Have you followed my advice? You don't need ES1 and ES2 on desktop environments.

Jotschi loads the native libraries whereas it is useless especially in the RC4, Sven added a mechanism able to load the native libraries from the JARs.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with GLProfile and jogl2-rc2

Sven Gothel
Administrator
In reply to this post by reyman
On Monday, October 24, 2011 12:37:23 PM reyman [via jogamp] wrote:
>
> Thanks, so i try the pre-RC4
>
> Another question, i want my application ready for different platform, so i
> use a custom loader like this :
> https://github.com/Jotschi/jogl2-example
>

I would like to discourage a custom loader.
With the new native JAR file loading, it works out of the box
for Standalone-Apps, WebStart and Applets(w/ or w/o JNLP).
See here:
  http://jogamp.org/deployment/jogamp-next/jogl-test-applets.html

The 'NApplet' launch mode is probably what you want:
 Applet just using Applet/Object or Embed tag, where native JARs are post-loaded by GlueGen/JOGL.

I have added this feature on the 23rd September
  http://jausoft.com/blog/2011/09/23/jogamp-deployment-enhancements-automatic-loading-of-native-jars-appletapplication/

also described in this forum post, which will soon be added to the doc/wiki:
  http://forum.jogamp.org/setting-up-JOGL-in-Eclipse-on-Mac-OSX-Lion-Frustration-td3435692.html#a3436274

If you have ideas how we can enhance it, I am all ears and your inspiration/code is very welcome.

+++

Looks like Joschi's work from 26th September overlaps a bit w/ ours:
  http://www.jotschi.de/?p=660

> Do you have an idea of the modification i change to use this with RC4 ?
> Loader is very different ?

Glancing over his blog entry, it looks like we are doing semantically the same,
hence you don't need Joschi's loader.

We also take good care of removing the temporary storage where the
native libraries (or other resources of the JARs) are being stored.
I see this is missing in Joshi's work (at least in the blog).

Another benefit of using our build-in mechanism is, that it is build-in
and complies with our BSD license.
So .. it just works our of the box.

~Sven
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with GLProfile and jogl2-rc2

gouessej
Administrator
You're right, Joschi uses the GPL, it can be used only by applications using the same licence.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with GLProfile and jogl2-rc2

reyman
This post was updated on .
In reply to this post by Sven Gothel
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 ... :-/
Do you have any experience with maven on this point ?

Best regards,
SR.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with GLProfile and jogl2-rc2

Sven Gothel
Administrator
On Monday, October 24, 2011 01:26:19 PM reyman [via jogamp] wrote:

>
> 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 ... :-/

Well, first of all I recommend moving to our new JOGL version.
You won't have support for JOGL 1.* from us, sorry.

Using the native JAR mechanism or the (old) standalone .so mechanism
(which is still possible) doesn't require unused files, ie other platforms native jars or .so's.

In short .. ofc you can pick and deploy only the required files (java/platform),
either via our recommended *all* method or the atomic files (look in the atomic subfolder).
  http://jogamp.org/jogl/doc/deployment/JOGL-DEPLOYMENT.html

> Do you have any experience with maven on this point ?

Thats currently our weak point.
A few have started this effort, but sadly nobody finished it .. lack of commitment :(
If you or anybod else would like to pick up this task and finally finishes it,
it would be greatly appreciated!
For maven .. we would like to use our jogamp.org server and our releases, if possible.

~Sven

>
> Best regards,
> SR.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with GLProfile and jogl2-rc2

reyman

Can you give me one cursor of your class (javadoc or src code) which load the java native packaged into jar ?

So after discussion, we are interested by your mechanism. But, do you think it's possible to deploy two and only two big jar (gluegen and jogl) which contain all native class for all plateform ?  In this case, i think it's very easy to deploy this solution with maven.

We create a pom.xml for our project with glugen-rt-all.jar and jogl-all.jar, and it's rocks :)

Best Regards,
SR
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with GLProfile and jogl2-rc2

Sven Gothel
Administrator
On Monday, October 24, 2011 02:40:06 PM reyman [via jogamp] wrote:
>
> Can you give me one cursor of your class (javadoc or src code) which load
> the java native packaged into jar ?
>
I have mentioned the git sha1 / commits in my blog:
  http://jausoft.com/blog/2011/09/23/jogamp-deployment-enhancements-automatic-loading-of-native-jars-appletapplication/

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

> So after discussion, we are interested by your mechanism. But, do you think
> it's possible to deploy two and only two big jar (gluegen and jogl) which
> contain all native class for all plateform ?  In this case, i think it's
> very easy to deploy this solution with maven.

Make 4 of'em .. 2 pure java (gluegen-rt/jogl) and their 2 platform specific 'mates'.

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.

Moreover .. if we can merge this to our own deployment,
allowing others to use the maven* mechanism would be nice.

>
> Best Regards,
> SR

~Sven
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with GLProfile and jogl2-rc2

Sven Gothel
Administrator
In reply to this post by reyman
On Monday, October 24, 2011 02:56:46 PM Sven Gothel wrote:

> 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.
>
The ant property 'os.and.arch' is determined in target 'gluegen.cpptasks.detect.os' (import gluegen-cpptasks.xml):
  http://jogamp.org/git/?p=gluegen.git;a=blob;f=make/gluegen-cpptasks-base.xml;hb=HEAD#l482

dunno if you can use it this way from within a maven pom file

~Sven
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with GLProfile and jogl2-rc2

reyman
In reply to this post by Sven Gothel
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

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with GLProfile and jogl2-rc2

Sven Gothel
Administrator
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with GLProfile and jogl2-rc2

Michael Bien

On 10/24/2011 04:21 PM, Sven Gothel [via jogamp] wrote:

> 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
>

the ant tasks to generate poms are already there but not maintained
(will probably require some updates since they where not touched for a
year or so).
e.g.
https://github.com/mbien/gluegen/blob/master/make/maven-common.xml

i am using jocl with maven and it works quite good so far. Classpath
libloading (via gluegen) was trivial to implement.

no libpath anymore, yey.

i can't recommend to port the gluegen build itself to any declarative
build tool. Its far to procedural and doesn't map very well to
"convention over configuration", the nearest what would probably work is
gradle or something like that.

regards,

michael

--
http://michael-bien.com/

1234
Loading...