598 2012-06-25 21:46:05 +0200 JOGL ALL JAR File Change incl. it's Native Jar URL Derivation 2012-07-05 22:47:26 +0200 1 1 3 JogAmp Jogl core 2 All all RESOLVED FIXED --- blocker --- 1 sgothel sgothel gouessej org.jogamp rami.santina sgothel xixsimplicityxix --- gluegen 9a71703904ebfec343fb2c7266343d37a2e4c3db jogl a393e45613d87101dbb13763df263c2f9291d2d0 jogl-demos 1d1b473d08612d01d274642113ea37a7052daceb joal faefb3ed4e9876dd1f756500caed3904604a11cf jocl 95bf6160c908364fbce2f82df85063d12c9b279c jocl-demos 0e6bf2a0a9b3df729d6984bdc1a857889a3c1bdf --- oldest_to_newest 1663 0 sgothel 2012-06-25 21:46:05 +0200 Currently JOGL uses an inconsistent 'all' JAR file name: - jogl.all.jar - jogl.all-mobile.jar - jogl-all-natives-<os.and.arch>.jar where all other 'all' JAR file names, including the native JAR files are: - <module>.jar - <module>-natives-<os.and.arch>.jar Mark Raynsford is currently working on our Maven repository and pointed out it's inconsistency. <http://forum.jogamp.org/Jar-file-name-pedantry-td4025305.html> +++ I double checked our native JAR file loading mechanism, which gives this change a technical motivation. +++ GlueGen - JNILibLoaderBase: public static boolean addNativeJarLibs(Class<?> classFromJavaJar, String allNativeJarBaseName, String[] atomicNativeJarBaseNames) {..} JOGL - GLProfile's usage: JNILibLoaderBase.addNativeJarLibs(GLProfile.class, "jogl-all", { "nativewindow", "jogl" }); +++ The above indicates (which is true) that we derive the native JAR URL by: <URI path from 'classFromJavaJar'> + "/" + 'allNativeJarBaseName' + "-" + <os.and.arch> + ".jar" +++ The above does not allow us to change the JARs basename if required as it is intrinsic when using maven, for example. Of course, other situations may occur as well .. when dealing w/ custom user packaging. For example in maven, Mark figured out how to use a naming scheme like: - jogl-all-<version>.jar - jogl-all-<version>-natives-<os.and.arch>.jar Mark confirmed that this format is acceptable for us to use w/ Maven, providing the native jars as "classified" jars. <http://forum.jogamp.org/Jar-file-name-pedantry-tp4025305p4025320.html> +++ Yes, this still would 'only' work for the 'all' java package names, the atomic JAR naming scheme would still require the basenames. Maybe you have a good solution to this ? However, the 'all' JAR targets cover 99% of all of our use cases. The proposed jogl.all* Java name change would also lead to: +++ GlueGen - JNILibLoaderBase: public static boolean addNativeJarLibs(Class<?> classFromJavaJar, String[] atomicNativeJarBaseNames) {..} JOGL - GLProfile's usage: JNILibLoaderBase.addNativeJarLibs(GLProfile.class, { "nativewindow", "jogl" }); +++ The above would imply that we derive the native JAR URL by: <URI from 'classFromJavaJar' w/o ".jar" suffix> + "-" + <os.and.arch> + ".jar" +++ Yes, this change will also affect GlueGen and all other modules code. But since their names are consistent, it would not impact it's users, i.e. changing JAR names etc. +++ Note: It would be a bad workaround to attempt to load variations of native JAR URLs, since this would impact the loading time. Keep in mind that each attempt to load a URL might be a network connection. +++ I know this change would ask people to change their project files and us to change all our documentation and examples. Hence it has a huge impact. Question is, whether this remedy is worth the amount of work and probably the confusion. Please digest and give your statements. In the end, I think this change is a good and required one. 1664 1 gouessej 2012-06-25 21:55:21 +0200 Hi You should do it as early as possible or give it up in order to minimize the impact on all projects that rely on JogAmp. We cannot abandon Maven support, several contributors of thir party libraries really want us to provide it (Nifty GUI, Jzy3D, Ardor3D, etc...). 1666 2 sgothel 2012-06-25 22:13:50 +0200 (In reply to comment #1) > Hi > > You should do it as early as possible or give it up in order to minimize the > impact on all projects that rely on JogAmp. We cannot abandon Maven support, > several contributors of thir party libraries really want us to provide it > (Nifty GUI, Jzy3D, Ardor3D, etc...). Thank you for your agreement. I will do it now in branch 'maven' (gluegen, jogl). 1670 3 sgothel 2012-06-26 10:57:05 +0200 pushed maven branch of gluegen, jogl and jogl-demos - pls review. I have tested a few jar file scenarios manually (linux x86_64), - all existing all native JARs - missing all naytive JARs - all atomic [native] JARs works here. Further more a few optimization went into the GlueGen code avoiding repetitive ClassLoader look-ups and native JAR load attempts. 1671 4 sgothel 2012-06-26 11:26:24 +0200 (In reply to comment #3) > pushed maven branch of gluegen, jogl and jogl-demos - pls review. > > I have tested a few jar file scenarios manually (linux x86_64), > - all existing all native JARs > - missing all naytive JARs > - all atomic [native] JARs > works here. > > Further more a few optimization went into the GlueGen code > avoiding repetitive ClassLoader look-ups and native JAR load attempts. The GlueGen commit 9a71703904ebfec343fb2c7266343d37a2e4c3db handles the 'all' case, as well the 'atomic' JAR case. Hence the original disclaimer (no atomic) is invalid. 1672 5 sgothel 2012-06-26 11:33:19 +0200 Got the OK from Rami as well. Hence we have 4 core people who agree on the change (incl. Mark). Will merge to master to push joal and jocl as well and kick-off testing. 1673 6 rami.santina 2012-06-26 11:41:34 +0200 this looks as a good standard with performance advantages, i vote for it... Regards, Rami 1678 7 sgothel 2012-06-30 14:34:04 +0200 locally tested w/ signed JARs, jogl & jogl-demos test applets and webstart 1679 8 sgothel 2012-06-30 14:34:31 +0200 (In reply to comment #7) > locally tested w/ signed JARs, jogl & jogl-demos test applets and webstart .. and maven 1699 9 sgothel 2012-07-05 22:47:26 +0200 *** Bug 562 has been marked as a duplicate of this bug. ***