jogamp › general

Re: incorrect files in stable release

Classic

List

Threaded

10 messages Options

Sven Gothel

Re: incorrect files in stable release

Administrator

On Tuesday, February 01, 2011 18:21:03 [hidden email] wrote:
> Hi,
> First, thanks so much for taking on maintaining JOGL et. al. - it's a valuable service and greatly appreciated by the community.

Thank you.

Due to community interest and allow a followup discussion,
I have added our forum/ml for this purpose - hope that's OK with you.

>
> Now to the point: on the JOGL "Stable Release" page, a number of files (e.g. "jog-all.jar", "gluegen-rt.jar", and "nativewindow.all.jar") which are supposed to download jar files actually download gzipped versions of those files. For most people this isn't a problem -- unless you don't have a tool that recognizes a .gz file (and aren't sophisticated enough to deal with that). Anyway, it's confusing -- and I don't think this is what you intended, since each of those files is immediately followed by a link to a .gz file of the same name.

Well, it's a 'on-the-fly' solution to offer the file as compressed as possible
due to the client's 'Accept-Encoding (AE) field'.

You can verify this by fetching the file with 'wget' for example,
which doesn't offer any encoding, hence the plain JAR file is received.

Order of compression, if availble by the client via the AE is:
- pack200-gzip
- gzip
- plain

Our apache .htaccess file at http://jogamp.org/deployment/ :

+++

AddType application/x-java-archive .jar
AddType application/x-java-jnlp-file .jnlp

<Files *.jar.pack.gz>
AddEncoding pack200-gzip .jar
RemoveEncoding .gz
</Files>

RewriteEngine on
RewriteCond %{HTTP:Accept-Encoding} pack200-gzip
RewriteCond %{REQUEST_FILENAME}.pack.gz -f
RewriteRule ^(.*\.jar)$ $1.pack.gz [NC,L]

RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule ^(.*\.jar)$ $1.gz [NC,L]

+++

This is explained here:

http://www.thrysoee.dk/pack200/
http://download.oracle.com/javase/1.5.0/docs/guide/deployment/deployment-guide/pack200.html

Hope this helps ..

Sure, if there is a better solution _without_ using a servlet or whatsoever
we are happy to learn about it.

Note:
Manual download of these files is not a recommended choice anyways.
If you like to fetch the files for manual deployment,
please download the platform's zip folders in the archive subfolder:

http://jogamp.org/deployment/webstart/archive/

>
> Sincerely,
> John Clevenger
> Computer Science Dept.
> Cal State U, Sacramento
>

Cheers, Sven

Wade Walker

Re: incorrect files in stable release

Administrator

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

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?

Sven Gothel

Re: incorrect files in stable release

Administrator

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

gouessej

Re: incorrect files in stable release

Administrator

Personally I prefer only adding one line into my JNLP file than handling JOGL by myself.

Julien Gouesse | Personal blog | Website

Michael Bien

Re: incorrect files in stable release

In reply to this post by Wade Walker

Hi Wade,

On 02/02/2011 04:28 AM, Wade Walker [via jogamp] wrote:
> 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.
good question :)

as Sven already mentioned: we have two webstart folders,
one for major releases and one for early access stuff (random builds).

Imagine it would be a maven repository. Its ok for testing when you
always take the latest version but for production you may have the
requirement to build from a internal maven repo against fixed/known
dependency versions (speak hosting the libs on your own server).

But you could still decide to link to our server (balls of steel as
precondition) which is absolutely fine since we can host every
incompatible version under a different namespace.

lets say JOGL 2 is released and we do a jogamp bundle.. we may host all
subsequent updates as
/webstart-2.0 as long we don't break compatibility.
If we break compatibility we just add another folder (e.g /webstart-2.5).

Developers could use the bleeding edge webstart-next for demos and
testing since they can live with the risk that it can break anytime.

The deployment isn't finished yet and we agreed to don't loose to much
time with it before 2.0... we can always optimize it later.

comments? :)

best regards,
michael

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

Sven Gothel

Re: incorrect files in stable release

Administrator

On Wednesday, February 02, 2011 17:33:10 Michael Bien [via jogamp] wrote:

>
> Hi Wade,
>
> On 02/02/2011 04:28 AM, Wade Walker [via jogamp] wrote:
> > 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.
> good question :)
>
> as Sven already mentioned: we have two webstart folders,
> one for major releases and one for early access stuff (random builds).
>
> Imagine it would be a maven repository. Its ok for testing when you
> always take the latest version but for production you may have the
> requirement to build from a internal maven repo against fixed/known
> dependency versions (speak hosting the libs on your own server).
>
> But you could still decide to link to our server (balls of steel as
> precondition) which is absolutely fine since we can host every
> incompatible version under a different namespace.
>
> lets say JOGL 2 is released and we do a jogamp bundle.. we may host all
> subsequent updates as
> /webstart-2.0 as long we don't break compatibility.
> If we break compatibility we just add another folder (e.g /webstart-2.5).

yup .. discussed this with Michael and we will change to this idea a bit
to provide stable API <major.minor> binaries.

>
> Developers could use the bleeding edge webstart-next for demos and
> testing since they can live with the risk that it can break anytime.
>
> The deployment isn't finished yet and we agreed to don't loose to much
> time with it before 2.0... we can always optimize it later.

yup

if nobody has any concerns, we may move over to 'webstart-2.0' right away.

the policy for such a webstart-<version> folder will be as follows:

- while 2.0 is being in development (RC stuff) - things can happen (API)

- after 2.0 the API shall be stable / frozen and only fixes will follow up,
which is very unlikely since we kind of agreed to a forward development.

we may continue 'webstart' reflecting the lastest webstart-<version> one
for your bleeding edge stable convenience - wow .. another release thing :)

>
> comments? :)
>

We sure will find more ways to make it more complicated :)

~Sven

Wade Walker

Re: incorrect files in stable release

Administrator

In reply to this post by Michael Bien

I don't feel too strongly about it, since I'm not working on web start right now. But the carbon content of my balls is far too low to link my app against someone else's remote server and hope their update doesn't break me

I guess this deployment allows users to just insert one line in their JNLP to get all of JOGL, so they don't have to copy the JOGL JNLP file and change the insides to point to their own server. But we've already seen users bitten by version incompatibility on the forum (like this guy at http://jogamp.762907.n3.nabble.com/Applet-throwing-NoSuchMethodException-tp2335825p2349347.html).

Maybe I should write a wiki page on web start where I tell the possibilities of hosting (local filesystem, local web server, JogAmp web server) and mention the possible risks/benefits of each?

Michael Bien

Re: incorrect files in stable release

In reply to this post by Sven Gothel

comment inline..

On 02/02/2011 06:08 PM, Sven Gothel [via jogamp] wrote:

>
> On Wednesday, February 02, 2011 17:33:10 Michael Bien [via jogamp] wrote:
>> Hi Wade,
>>
>> On 02/02/2011 04:28 AM, Wade Walker [via jogamp] wrote:
>>> 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.
>> good question :)
>>
>> as Sven already mentioned: we have two webstart folders,
>> one for major releases and one for early access stuff (random builds).
>>
>> Imagine it would be a maven repository. Its ok for testing when you
>> always take the latest version but for production you may have the
>> requirement to build from a internal maven repo against fixed/known
>> dependency versions (speak hosting the libs on your own server).
>>
>> But you could still decide to link to our server (balls of steel as
>> precondition) which is absolutely fine since we can host every
>> incompatible version under a different namespace.
>>
>> lets say JOGL 2 is released and we do a jogamp bundle.. we may host all
>> subsequent updates as
>> /webstart-2.0 as long we don't break compatibility.
>> If we break compatibility we just add another folder (e.g /webstart-2.5).
> yup .. discussed this with Michael and we will change to this idea a bit
> to provide stable API<major.minor> binaries.
>
>> Developers could use the bleeding edge webstart-next for demos and
>> testing since they can live with the risk that it can break anytime.
>>
>> The deployment isn't finished yet and we agreed to don't loose to much
>> time with it before 2.0... we can always optimize it later.
> yup
>
> if nobody has any concerns, we may move over to 'webstart-2.0' right away.
>
> the policy for such a webstart-<version> folder will be as follows:
>
> - while 2.0 is being in development (RC stuff) - things can happen (API)
>
> - after 2.0 the API shall be stable / frozen and only fixes will follow up,
> which is very unlikely since we kind of agreed to a forward development.
>
> we may continue 'webstart' reflecting the lastest webstart-<version> one
> for your bleeding edge stable convenience - wow .. another release thing :)

we could use this (now webstart-next) for fully automated webstart
builds from master branch. All webstart-x.y releases should be promoted
manually anyway IMO.
(signed or not... i don't have a strong opinion on that)

-> Jenkins post-build job or something like that

>> comments? :)
>>
> We sure will find more ways to make it more complicated :)
>
> ~Sven
>
>
>
> _______________________________________________
> If you reply to this email, your message will be added to the discussion below:
> http://jogamp.762907.n3.nabble.com/Re-incorrect-files-in-stable-release-tp2399074p2406899.html
> To start a new topic under jogamp, email [hidden email]
> To unsubscribe from jogamp, visit
http://michael-bien.com/

Sven Gothel

Re: incorrect files in stable release

Administrator

In reply to this post by Wade Walker

On Wednesday, February 02, 2011 18:15:44 Wade Walker [via jogamp] wrote:

>
> I don't feel too strongly about it, since I'm not working on web start right
> now. But the carbon content of my balls is far too low to link my app
> against someone else's remote server and hope their update doesn't break me
>
> I guess this deployment allows users to just insert one line in their JNLP
> to get all of JOGL, so they don't have to copy the JOGL JNLP file and change
> the insides to point to their own server. But we've already seen users
> bitten by version incompatibility on the forum (like this guy at
> http://jogamp.762907.n3.nabble.com/Applet-throwing-NoSuchMethodException-tp2335825p2349347.html).
>
> Maybe I should write a wiki page on web start where I tell the possibilities
> of hosting (local filesystem, local web server, JogAmp web server) and
> mention the possible risks/benefits of each?

remember: until 2.0 we are on the edge anyways.

after 2.0 is out, we are stable - 1st stable release
and able to provide a stable URL for those resources.

so we will do webstart-2.0 (I will notify you when it's done) ..
sure a user can do their own stuff, but we also should stand behind
what we provide as well.

~Sven

Sven Gothel

Re: incorrect files in stable release

Administrator

In reply to this post by Wade Walker

On Wednesday, February 02, 2011 05:02:09 Sven Gothel wrote:
> 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.

I fixed the wiki in this regard:

http://jogamp.org/wiki/index.php/Jogamp_Versioning_and_Releases
- added direct link to Platform ZIP archive's

http://jogamp.org/wiki/index.php/Downloading_and_installing_JOGL
- Fixed release installation docs to use platform ZIP archives
- Clarified Unzipping Files

sorry for x-posting.

~Sven