Note: the idea is to package most of the doc in the code. This is just a place holder for things that have not been moved there yet. This page will gradually disappear.

See also the latest deployed doc

Getting started

Plugin stability

The code is stable today and used by different people in several projects. The plugin is not yet available from the snaphosts codehaus repository. The main reasons is that we plan to make some small incompatible changes to stabilize the interface. Once these changes will be done (in the coming days), the plugin will be updated and hopefully all information related to building the plugin will ne online.

Checking out and building the plugin

See Subversion at the haus for subversion tips.

The code can be checked out doing:

current build issues

• Today the mojo-sandbox parent pom is a snapshot (2-SNAPSHOT). You may need to install the parent's pom in your local repository to be able to build. Hopefully that may change somehow. Just do:
  from the parent directory. If you don't feel like checking the whole mojo-sandbox package, you can get the pom from mojo-sandbox pom

• The plugin also depends on the keytool-maven-plugin v 0.3 or more. As of today, the codehaus snapshots repository doesn't contain this version of the keytool plugin. You will have to get it from mojo-sandbox, build it and install it in your local repository.

Hopefully these 2 build issues will be solved soon by deploying a stable version of the plugin on the snapshots repository!

contacting us

use user@mojo.codehaus.org. Feel free to copy me if I don't answer within 48h (jerome.lacoste@gmail.com)

adding new features

We already have some ideas on where to go from there, and patches waiting to be committed. So it is recommended that you contact us before adding new features so that we don't duplicate work or go in different directions. It would be sad to see code and efforts wasted!

Intent

Ease deployment of webstart applications for m2.
Will incorporate m1 JNLP and Webstart plugins.

We need your help

Requires input on proposed pom.xml specs. Feel free to pick up a* task. See also the* proposed proposal

Tell us your use cases:

• do you deploy webstart on static pages?
• which JDK do you support?
• do you use native libraries?
• do you localize your jnlp file? If so, at which phase of the delivery?
• do you deploy multiple webstart apps at once? (multiple versions, multiple jnlp files). What differentiates them?
• do you want pack200 to work?
• do you want to use the jnlp servlet?
• missing any feature from the current m2 webstart plugin config? (sending us a jnlp file would be great)

Statuses

• initial code checked in mojo-sandbox/webstart-maven-plugin
  • 17 Nov 2005 all m2 blocking issues have been checked in! You can start using the plugin using the m2 trunk. See links.
  • sign jar verification checked in in maven-jar-plugin
  • keytool plugin checked in mojo-sandbox
• implementation status:
  • jnlp generation now depends on user supplied templates
  • way to filter out jars from the transitive dependencies (or to exactly specify them):

• • keystore generation 100%
  • signing 100%
  • signing verification 100%
  • pack200 100% (using Sun's ant tasks)
  • multiple jnlp apps 100% (works by user using the assembly plugin to create your own webapps)
  • web.xml 0% (user has to modify it)
  • integration tests 0%
  • performance tuning 25%
    • we now do not re-sign the jar files if the source haven't changed
  • doc 60% (this page + internal documentation)

Existing code in other projects

maven 1

http://maven.apache.org/plugins-sandbox/webstart/

Provides the following features:

• Ability to setup the Webstart Cache in any location on the hard-disk, not necessarily the Webstart default which is in the User Home. This Webstart Cache is where Webstart will download all the jars to launch a particular application
• Ability to start the application locally. This is especially useful if the Application Server on which the application is deployed is at a Remote location and the connection speed is not too fast. Webstart by default connects to the Application Server each time to check the version of the jars. The plugin provides a feature wherein the application is downloaded and then run on localhost thereby reducing the time Webstart spends in detecting version updates.
• Ability to launch Webstart to open the application specified in the JNLP file provided.

jelly script notes

• some fields are automatically initialized
   
   
  -> to use this we have to break down the dname property in the gen-jnlp

• jnlp file creation. StringBuffer vs Velocity

• dependencies. They must be listed somehow. Kris proposed something like:
   
   

• jelly script uses many dependency properties. 'jnlp.main.jar', jnlp.native.jar, jnlp.extension.jnlp, jnlp.extension.site, jnlp.extension.dir

algorythm

ant-jnlp-war

http://ant-jnlp-war.sourceforge.net/

features

• uses velocity to generate the jnlp file
• offline-allowed
• pack200
• redistributes jnlp-servlet.jar
• packages one app into a war. We probably want more flexibility

questions:

• ant task license? http://ant.apache.org/external.html says ASL 2.0. Confirmed by author on MOJO-82 issue.
• can we redistribute jnlp-servlet.jar? Yes but not the SDK 5.0 version See below.

algorythm

See ant-jnlp-war/src/core/org/unintelligible/antjnlpwar/task/JnlpWar#execute

misc

Before I forget, notify the ant-jnlp-war developer(s) or the issue they have in the following Velocity template (wrong element closing)

jnlp-servlet

SDK 5.0 license

not redistributable

Mustang license

Credit to Philipp Meier for retrieving it.

I.e. BSD License + nuclear clause

Proposal

Functioning

See internal doc

Architecture

Reuse or made reusable several part of the implementation:

• org.apache.maven.plugins:maven-jar-plugin for sign and sign-verify goals
• org.codehaus.mojo:keytool-maven-plugin for genkey goal
• jnlp-servlet and pack200 ant tasks to be deployed in ibiblio

Input/Output

See internal doc

JNLP file generation

See internal doc

proposed web layout

See internal doc

war web layout

When working with a project ot type war (future implementation), we could also

jnlp-servlet support

JNLP file

• $$codebase, $$name and $$context expansion
• TimeStamp formatting. How does the user specify the timestamp?
• version download protocol creates some differences in the way the file is formatted.

web.xml

should we modify it automatically ? (to add jnlp-servlet reference)

pom.xml examples

Most of this was moved inside the internal doc

Specify below how the user should write his pom.xml to achieve his goals.

Order below doesn't reflect priority

potential pom.xml spec...

See internal doc

RFC: multiple JNLP

The idea is to support producing a single ZIP with multiple webstart applications, signed using the same keys. Main goal is to allow speed up.

Fip layout:

Signing info is unique for the multiple webapplications. Jars are signed/packed once.
I am thinking of modifying the JNLP config to something like:

RFC: extraction of the configuration elements into a separate XML file, a-la assembly plugin

I intend to extract the config into it's own file. Any objection?

jnlp-servlet support

NOT YET SUPPORTED

This will have to be done in 3 phases:

• make sure the jnlp-servlet is available somewhere (See MAVENUPLOAD-559)
• configure your webstart plugin to support jnlp-servlet (pack200, version.xml, launch.jnlp files)
• configure your war (modify WEB-INF/web.xml, bundle jnlp-servlet)

TODO

List of tasks to do. If you want to do something, write your name.

• see if we can reuse 'unknown''s idea to not support the jnlp spec inside the pom.xml but just process a jnlp template file (see comments). We first need to identify what is really created by the plugin.

• find out what to do with the missing pack200 project...

• move the doc from this page into the plugin.

• specs: investigate the various use cases.

• the plugin is not optimized for speed. Areas were it could be improved:
  • pack the various dependencies into a single jar. Will reduce the number of jarsigning, packing operations
  • avoid resigning/repacking if the dependencies didn't change (and if the pom.xml and referenced key elements didn't change neither)
  • try to share things between multiple webapps that depends on the same dependencies (probably harder)
• define unit tests strategy. Should we try to test pack200 and zip operations? How?

Misc

keystool:genkey

• Status: committed to mojo-sandbox.

You can program it like that:

These are just the minimum parameters one must use. There are around 10 parameters available.

Comment from Philipp Meier: we have to make sure that specifying the passwords outside of the pom will work. This being the command line or properties file.

Links

http://www.vamphq.com/sophie/ collection of apps, many related to JNLP
http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/pack200.html
See also MOJO-7
See also MOJO-82
See also MMN-1130
See also MNG-1251
See also MNG-1274
See also MNG-1310
See also MNG-1311
See also MNG-1462
See also MNG-1588
See also MAVENUPLOAD-559
See also MAVENUPLOAD-560
See alo https://sun-jnlp-servlet.dev.java.net/, where I will put the maven jnlp servlet jars, forked from Mustang.

http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Matrix