The plugin currently supports everything necessary to best support Java Webstart for Java 7 and newer without the need for a specialized download servlet (which was required prior Java 7 to achive the same functionality).
=> http://docs.oracle.com/javase/tutorial/deployment/deploymentInDepth/bestPractices.html
Part of the best practices mentioned in the above link are not in the scope of this plugin: Everything that has to be done in the HTML file must be done by the project using this plugin.
This is especially true for the codebase attribute. You either have to hard-code the codebase in the build.gradle to the value of the server, follow http://docs.oracle.com/javase/tutorial/deployment/deploymentInDepth/deployingWithoutCodebase.html (i.e. create a HTML file containing some javascript), or use the download servlet (which is not directly supported right now).
But one last piece is missing: the JnlpDownloadServlet does support JarDiff download to further reduce the download. This is not possible using just client side techniques available till Java 7.
The purpose of this issue can be split in two parts:
Investigate possibilities of Java Webstart regarding JarDiff/Pack200
- What is JarDiff (File format, etc.)? It seems, the JarDiff is just a jar file (http://www.informit.com/articles/article.aspx?p=25044&seqNum=6)
- Can JarDiff be combined with Pack200? Since a JarDiff is just a jar file, I would hope this to be true, but it must be checked if this is supported by the Webstart client
- What gains can be expected
If it is worth it, implement JarDiff support
This only makes sense when creating a war file. Therefore, this would only work for war projects, i.e. projects with plugin 'war' applied
- Automatically (maybe configured using the extension) add a dependency to the JnlpDownloadServlet
- don't generate jnlp.packEnabled and jnlp.versionEnabled properties in the jnlp (this must be handled by the servlet instead of the client in that case)
- Configure the old version(s) to also be included
Either by defining a dependency on both the new version and the old version(s) of the application
configurations {
jnlpV1
jnlpV2
// ...
}
dependencies {
jnlp 'group:artifact:v3'
jnlpV1 'group:artifact:v1'
jnlpV2 'group:artifact:v1'
}The plugin would collect all dependencies from configurations which name startsWith 'jnlp' and put all the jars signed and packed and versioned in the lib directory.
Or by defining a dependency on both the new version of the application and the old version(s) of the war
This may be a special case of the above, but instead of defining a dependency for jnlpV1 on the application with an older version, there would be a dependency on an older version of the war. In that case the plugin would not have to sign and pack the jars, because the war does already contain signed and packed jars.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent