Oracle put more strict rules on jnlp (see https://blogs.oracle.com/thejavatutorials/entry/jdk_7u45_and_javafx_2) for more informations

To fix this, you need to add some manifest entries to all the jars used in the jnlp file. This can be done by simply adding something like this in your pluging configuration:

           <updateManifestEntries>
             <Permissions>all-permissions</Permissions>
             <Codebase>*</Codebase>
           </updateManifestEntries>
         

[top]

The plugin doesn't obfuscate JARs but it can deploy JARs that have already been obfuscated.

One approach would be to use the proguard-maven-plugin to obfuscate the JARs and the build-helper-maven-plugin to attach the obfuscated artifact to the project along with the unobfuscated JAR and install them both in your local repository. Then when you configure the Webstart Plugin with the dependencies to be deployed in your JNLP bundle, you can choose between the obfuscated or unobfuscated JARs.

[top]

The servlet cannot yet be found on an central Maven repository. For demonstration purposes, the webstart project packages one version under the (currently) following identifiers

      <groupId>org.codehaus.mojo.webstart-maven-plugin</groupId>
      <!--groupId>com.sun.java.jnlp</groupId-->
      <artifactId>jnlp-servlet</artifactId>
      <version>1.0-6.0-02_ea_b02-SNAPSHOT</version>

[top]

Right now, deployment is not supported out of the box by the plugin. We may add the support in the near future (See MWEBSTART-25). You may want to use the Wagon Maven Plugin in the mean time.

[top]

For technical reason this is not possible unless you owns also the certificate used to signed jar.

You could then just unsign all signed jar, but this is not reccomended, since then you are atesting to the other partys code, and may be violating several agreements..

For more informations see this thread : https://forums.oracle.com/forums/thread.jspa?threadID=1304857

[top]

• The jnlp mojo is
  • aggregator
  • FORKS a build lifecycle and won't install the zip packages in your local repository
  • attached to the package phase, so you can invoke it from commandline
• The jnlp-inline mojo is
  • aggregator
  • does NOT fork a build lifecycle and won't install the zip packages in your local repository
  • NOT attached to any phase (you can't invoke it from commandline)
• The jnlp-single mojo is
  • NOT aggregator
  • does NOT a build lifecycle and won't install the zip packages in your local repository
  • NOT attached to any phase (you can't invoke it from commandline)

• Do I need a aggregator mode?
• Do I need to invoke it from commandline?
• Do I need to execute the mojo in a forked build lifecycle?

[top]