Hi,
I am the author of the gradle-jnlp-plugin
(https://github.com/tschulte/gradle-jnlp-plugin/). It's purpose is the
same as your webstart-plugin, just for gradle.
As a young project I had the luxury of only having to target Java 6u10
or newer. Therefore it does not need the support of the
JnlpDownloadServlet but instead uses the properties jnlp.packEnabled and
jnlp.versionEnabled and allows deploying the files to any http server.
But now I wanted to implement jardiff support and am in the need for the
DownloadServlet again. Therefore I did some tests to see what the
JnlpDownloadServlet can do here.
The problems I saw are:
- You have to put both the jar and the jar.pack.gz files in the war to
get version 1 of the application running at all.
- The servlet generates the jardiff when upgrading to version 2 of the
application, but it will still deliver the v2.jar.pack.gz, if that file
is smaller than the jardiff.jar. It does not support packing the jardiff
with pack200
I did test this with my own implementation of the jar download protocol
in a 91 loc servlet. I think the JnlpDownloadServlet does too much:
- it supports JNLP 1.0 and 1.1 clients and has plenty of code for this
- it allows using version.xml or __Vversion.jar file pattern. Just going
with __Vversion.jar[.pack.gz] would allow to reduce the complexity.
- it needs both .jar and .jar.pack.gz to work correctly
- it generates the jardiff at runtime, but needs the .jar of both
versions. If only upgrade should be supported, packing the jardiff files
instead of the original jar files would reduce the war-size.
Therefore I suggest implementing a new DownloadServlet:
- targeting only Java 7 or newer
- targeting Servlet 3.0 or newer (allowing Annotation)
- Only using __Vversion.jar[.pack.gz] file pattern
- Allow only packing the .jar.pack.gz files to reduce the size of the war.
- not generating jardiff on the fly, offloading their generation to the
buildtool, adding the jardiff.pack.gz files to the war
- Not doing replacements of $$name, $$codebase, etc. For this I plan
implementing a separate Servlet, maybe using some templating engine like
FreeMarker.
That said, you guys are most probably the people knowing the existing
JnlpDownloadServlet best. Am I completely off track here? Would it be
wiser to just try to add the missing features to the existing
JnlpDownloadServlet?
I would really appreciate your input either here on the mailing list or
at https://github.com/tschulte/gradle-jnlp-plugin/issues/19.
Regards,
Tobias
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
