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.