Posted by Sven Gothel on Feb 02, 2011; 4:02am
URL: https://forum.jogamp.org/Re-incorrect-files-in-stable-release-tp2399074p2402958.html

On Wednesday, February 02, 2011 04:28:18 Wade Walker [via jogamp] wrote:
>
> I like how the new "zip" links on the front page point to the "archive"
> directories for webstart and webstart-next. I think this will avoid some
> confusion from users who try to download JOGL manually to deploy on their
> own servers. I ran into this .gz problem myself

Yup, Michael and myself discussed it as well - he took the initiative.
Good job.

>
> Speaking of which, is it ever a good idea for JOGL web start users to point
> to http://jogamp.org/deployment/webstart/ in their JNLP files? It seems like
> this just creates the possibility of their app breaking whenever the newest
> JOGL changes something, with their local JARs staying the same.
>
> Maybe I just don't understanding the usage model correctly? Why do we serve
> up these files in a form that other peoples' web start apps can use? Why not
> just make everyone serve the JOGL JAR files themselves?

Well, it's the JNLP model and we also provide signed binaries for
JNLP, Applets and JNLP-Applets within our deployment strategy.

Historically we offered 'webstart' and 'webstart-next',
the latter for experimental, maybe less stable code.
This is currently documented in the front page and
http://jogamp.org/wiki/index.php/Jogamp_Versioning_and_Releases .

Both folders contain the latest in regards their semantics,
manually promoted/deployed.

Since our JNLP files have the attribute:
        <update check="background" policy="always"/>

Right now we allow to start with the currently cached version
but trigger a background update, which allows to use the new stuff
with the next JVM launch.
This is much faster then doing the update check incl. downloads upfront.

Of course, anybody can server their own location since we don't sign
the JNLP files - but for convenience and easy to use we provide
this legit canonical source. Not everybody likes to deploy _and_ maintain
the whole thing. But they can, sure.

The next thing is to also deploy maven files, let's see how that goes :)

Cheers, Sven