New Deployment FHS (Filesystem Hierarchy Standard)

New Deployment FHS (Filesystem Hierarchy Standard)

See
  [1] http://jogamp.org/deployment/archive/master/gluegen_400-joal_202-jogl_471-jocl_407/

Month ago some of us discussed an easier deployment filesystem layout
in contrast to
  [2] http://jogamp.org/deployment/archive/master/gluegen_306-joal_137-jogl_329-jocl_295/

As you can see, [2] is pretty much spammed with jar files,
and it might not be easy to navigate through it.
Sure, it's not really a humans task to do that .. however.

While elaborating about it, we actually had a few nice ideas:

[a] better sorting of archives (developer files)
[b] creating one big jogamp archive file per platform (like eclipse)

Both is addressed and visible here:
  http://jogamp.org/deployment/archive/master/gluegen_400-joal_202-jogl_471-jocl_407/archive/

(Yes, still using the great 7z compression to save tons of diskspace)

http://jogamp.org/deployment/archive/master/gluegen_400-joal_202-jogl_471-jocl_407/
    archive/
        jogamp-linux-amd64.7z

        jogamp-linux-amd64/
            gluegen-linux-amd64.7z
            jogl-linux-amd64.7z
            ..
            test-results/
                ..

        jogamp-linux-i586.7z
        jogamp-linux-i586/
            ..

        jogl-javadoc.7z
        jogl-demos.7z
        ..

    jar/
        atomic/

    javadoc/
   
    jogl-demos/
        jar/

    log/

Developers have access to both, the original module's 7z platform archive
and the merged jogamp platform archive.

The test results are moved to a local subfolder as well.

The JNLP files are still in there original location,
just updated by the new JAR location in ./jar

I hope this matches how we desired it, ofc we can fix glitches etc.

+++

The root filesystem will change as follows:

http://jogamp.org/deployment/
    v2.0-rc2/
   
    v2.0-rc3/

    jogamp-current/ -> v2.0-rc3

    jogamp-next/ -> archive/rc/gluegen_xx-joal_yy-jogl_zz-jocl_uu-signed


[r1] contains the release version using the release tag version, ie v2.0-rc3
[r2] using symbolic links to allow generic use, ie jogamp-next

Both allows either using the latest or current/stable version
while also using a specified one, ie v2.0-rc2.

The latter maybe a variation for some web application, not willing to update/test
new versions.

+++

Remarks ? Replies ? Critizism ? All is welcome.

Cheers, Sven

Thanks for this new version and thanks for the simplification of the whole jar stuff.

I have several questions/requests:
* On the URL: http://jogamp.org/deployment/jogamp-current/
Could it be possible to have also jogl and gluegen tarballs with the sources
* http://jogamp.org/deployment/jogamp-current/jar/
it would be nice to show somewhere which version is it
* Will the jar names change again before the stable release ?

By the way, do you have any ETA on the stable release ?

thanks
Sylvestre

On Friday, September 16, 2011 05:36:33 PM sylvestre [via jogamp] wrote:
>
> Thanks for this new version and thanks for the simplification of the whole
> jar stuff.
>
> I have several questions/requests:
> * On the URL: http://jogamp.org/deployment/jogamp-current/
> Could it be possible to have also jogl and gluegen tarballs with the sources

Yes, will add some.

> * http://jogamp.org/deployment/jogamp-current/jar/
> it would be nice to show somewhere which version is it

The JAR manifest contains all version info, plus they are dumped to:
  http://jogamp.org/deployment/jogamp-current/log/

Then jnlp files say it's v2.0-r3.
Yes, we should add a file 'stamp' saying it's v2.0-rc3 as well, I guess.

> * Will the jar names change again before the stable release ?
I hope not :)

>
> By the way, do you have any ETA on the stable release ?
v2.0-rc3 is stable and it is a release!

mobile release builds will follow up
and hopefully bug fixes.

>
> thanks

Thank you Sylvestre.

> Sylvestre

~Sven

Hi!

It is important to keep atomic JARs and to modularize the APIs which compose JogAmp because:
- Java Web Start on Oracle JVM (not on OpenJDK) does not show the details of downloaded JARs. The progress bar is not updated during a download, the user can think that the installation has failed. If you use smaller JARs, the progress bar is updated more often which gives a better feedback
- some high level APIs and engines will not use some components of JOGL, for example the new text API. They should not have to use the biggest JAR
- the most direct competitor of JogAmp claims to be lightweight. If the APIs of Jogamp become bigger, some people might have the feeling that they have to download too much things or useless things, that is why a proper modularization is important for deployment too.