Maybe it's time to change version naming from "1.0-beta-8" to "1.0.8"?

Hi, I trying to use maven webstart plugin download servlet. And I have this issue:

The number of signed artifacts (1) differ from the number of modified artifacts (2). Implementation error -> [Help 1]

This issue is due to the fact that resource.zip is adding to the modifiedJnlpArtifacts list but not signed.
I think that zip files must be ignored from jar resources.

Change can be done on JnlpDownloadServletMojo on line 551.

In cases where the files are being resolved from a repository manager the resulting entries contain timestamps which influence the scan performance. This should be replaced with the -SNAPSHOT which is the same name as the jar file itself.

Could we get a release so that I could not have bug #6 ? Or is this project really just dead?

But this fails in the initialization of SignConfig:

Caused by: org.apache.maven.plugin.MojoExecutionException: Could not obtain key store location at ...RouteConverterWebstart>/NONE
at org.codehaus.mojo.webstart.sign.SignConfig.init(SignConfig.java:239)
at org.codehaus.mojo.webstart.AbstractBaseJnlpMojo.signOrRenameJars(AbstractBaseJnlpMojo.java:668)
at org.codehaus.mojo.webstart.AbstractJnlpMojo.execute(AbstractJnlpMojo.java:286)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 20 more

I have a build organized in the way that a webstart-maven-plugin is used to create a webstart distribution only. Jars are signed later by maven-jarsigner-plugin. By default maven-jarsigner-plugin tries to sign the main artifact as well but it fails because main jar file looks locked:

[DEBUG] Processing C:\workspace\sample\target\sample-0.0.1-SNAPSHOT.jar
[DEBUG] cmd.exe /X /C ""C:\Program Files\Java\jdk1.8.0_65\jre\..\bin\jarsigner.exe" -keystore C:\workspace\sample/etc/webstart/devstore.jks -storepass ***** C:\workspace\sample\target\sample-0.0.1-SNAPSHOT.jar dev"
[DEBUG] Executing: cmd.exe /X /C ""C:\Program Files\Java\jdk1.8.0_65\jre\..\bin\jarsigner.exe" -keystore C:\workspace\sample/etc/webstart/devstore.jks -storepass ***** C:\workspace\sample\target\sample-0.0.1-SNAPSHOT.jar dev"
[DEBUG] jarsigner: attempt to rename C:\workspace\sample\target\sample-0.0.1-SNAPSHOT.jar to C:\workspace\sample\target\sample-0.0.1-SNAPSHOT.jar.orig failed

I have track down that this lock is because of URLClassLoader instance created in org.codehaus.mojo.webstart.util.DefaultArtifactUtil.artifactContainsClass(Artifact, String) method.
This piece of code below fixes the problem but is Java 1.7+ specific:

@Override
public boolean artifactContainsClass( Artifact artifact, final String mainClass )
            throws MojoExecutionException
{
  ...
  URLClassLoader cl = new java.net.URLClassLoader( new URL[] { url } );
  ...
  // close the class loader
  try
  {
    cl.close();
  }
  catch( IOException e )
  {
    getLogger().warn( e.getMessage() );
  }
...
}

As a workaround I have configured the maven-jarsigner-plugin to not to sign the main artifact; it only signs the webstart distribution.

I'm using the 1.0-beta-7 version of the plugin. This version locks the jars. I have tested the 1.0.0-SNAPSHOT version as well which also locks the jars.

I was using 1.0-beta-2 and everything is ok, then I changed to 1.0-beta-6, and got the following error.

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 7.106 s
[INFO] Finished at: 2015-09-23T18:06:46-07:00
[INFO] Final Memory: 19M/279M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.codehaus.mojo:webstart-maven-plugin:1.0-beta-6:jnlp-inline (default) on project applet: Execution default of goal org.codehaus.mojo:webstart-maven-plugin:1.0-beta-6:jnlp-inline failed: A required class was missing while executing org.codehaus.mojo:webstart-maven-plugin:1.0-beta-6:jnlp-inline: Lorg/codehaus/mojo/keytool/KeyTool;
[ERROR] -----------------------------------------------------
[ERROR] realm =    plugin>org.codehaus.mojo:webstart-maven-plugin:1.0-beta-6
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] = file:/home/mayli/.m2/repository/org/codehaus/mojo/webstart-maven-plugin/1.0-beta-6/webstart-maven-plugin-1.0-beta-6.jar
[ERROR] urls[1] = file:/home/mayli/.m2/repository/org/codehaus/mojo/webstart-pack200-api/1.0-beta-6/webstart-pack200-api-1.0-beta-6.jar
[ERROR] urls[2] = file:/home/mayli/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.1/plexus-interpolation-1.1.jar
[ERROR] urls[3] = file:/home/mayli/.m2/repository/commons-cli/commons-cli/1.0/commons-cli-1.0.jar
[ERROR] urls[4] = file:/home/mayli/.m2/repository/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar
[ERROR] urls[5] = file:/home/mayli/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
[ERROR] urls[6] = file:/home/mayli/.m2/repository/org/apache/maven/reporting/maven-reporting-api/2.0.10/maven-reporting-api-2.0.10.jar
[ERROR] urls[7] = file:/home/mayli/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.0-alpha-11/doxia-sink-api-1.0-alpha-11.jar
[ERROR] urls[8] = file:/home/mayli/.m2/repository/org/apache/maven/reporting/maven-reporting-impl/2.0.4/maven-reporting-impl-2.0.4.jar
[ERROR] urls[9] = file:/home/mayli/.m2/repository/commons-validator/commons-validator/1.2.0/commons-validator-1.2.0.jar
[ERROR] urls[10] = file:/home/mayli/.m2/repository/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar
[ERROR] urls[11] = file:/home/mayli/.m2/repository/commons-digester/commons-digester/1.6/commons-digester-1.6.jar
[ERROR] urls[12] = file:/home/mayli/.m2/repository/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar
[ERROR] urls[13] = file:/home/mayli/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
[ERROR] urls[14] = file:/home/mayli/.m2/repository/org/apache/maven/doxia/doxia-core/1.0-alpha-7/doxia-core-1.0-alpha-7.jar
[ERROR] urls[15] = file:/home/mayli/.m2/repository/oro/oro/2.0.7/oro-2.0.7.jar
[ERROR] urls[16] = file:/home/mayli/.m2/repository/org/apache/maven/doxia/doxia-site-renderer/1.0-alpha-7/doxia-site-renderer-1.0-alpha-7.jar
[ERROR] urls[17] = file:/home/mayli/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta-6/plexus-i18n-1.0-beta-6.jar
[ERROR] urls[18] = file:/home/mayli/.m2/repository/org/codehaus/plexus/plexus-velocity/1.1.2/plexus-velocity-1.1.2.jar
[ERROR] urls[19] = file:/home/mayli/.m2/repository/commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.jar
[ERROR] urls[20] = file:/home/mayli/.m2/repository/velocity/velocity/1.4/velocity-1.4.jar
[ERROR] urls[21] = file:/home/mayli/.m2/repository/velocity/velocity-dep/1.4/velocity-dep-1.4.jar
[ERROR] urls[22] = file:/home/mayli/.m2/repository/org/apache/maven/doxia/doxia-decoration-model/1.0-alpha-7/doxia-decoration-model-1.0-alpha-7.jar
[ERROR] urls[23] = file:/home/mayli/.m2/repository/org/apache/maven/shared/maven-shared-utils/0.5/maven-shared-utils-0.5.jar
[ERROR] urls[24] = file:/home/mayli/.m2/repository/com/google/code/findbugs/jsr305/2.0.1/jsr305-2.0.1.jar
[ERROR] urls[25] = file:/home/mayli/.m2/repository/org/apache/maven/shared/maven-jarsigner/1.3.1/maven-jarsigner-1.3.1.jar
[ERROR] urls[26] = file:/home/mayli/.m2/repository/org/codehaus/plexus/plexus-archiver/2.4.1/plexus-archiver-2.4.1.jar
[ERROR] urls[27] = file:/home/mayli/.m2/repository/org/codehaus/plexus/plexus-io/2.0.7/plexus-io-2.0.7.jar
[ERROR] urls[28] = file:/home/mayli/.m2/repository/org/apache/commons/commons-compress/1.5/commons-compress-1.5.jar
[ERROR] urls[29] = file:/home/mayli/.m2/repository/org/tukaani/xz/1.2/xz-1.2.jar
[ERROR] urls[30] = file:/home/mayli/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.10/plexus-utils-3.0.10.jar
[ERROR] urls[31] = file:/home/mayli/.m2/repository/org/apache/velocity/velocity/1.7/velocity-1.7.jar
[ERROR] urls[32] = file:/home/mayli/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar
[ERROR] urls[33] = file:/home/mayli/.m2/repository/commons-lang/commons-lang/2.6/commons-lang-2.6.jar
[ERROR] Number of foreign imports: 1
[ERROR] import: Entry[import  from realm ClassRealm[maven.api, parent: null]]
[ERROR] 
[ERROR] -----------------------------------------------------: org.codehaus.mojo.keytool.KeyTool
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginContainerException

Hello,

previously there was an issue http://jira.codehaus.org/browse/MWEBSTART-266 with the patch attached
(to correctly work with latest java main jar should contain JNLP-INF/APPLICATION_TEMPLATE.jnlp with all parameters replaced with '*')
I tried to clone your repo to try to fix it myself but failed :(
can you point me to the right direction or maybe fix the issue?

additional problem I'm facing is forking, maybe you know how can 'no-fork' mode can be implemented

Thanks in advance, and sorry I was unable to provide the patch :(

Some of the dependencies artifacts are environment specific.
I would want to be able to provide execution configuration, to associate artifacts to the environment where they are required. If no associating is provided, plugin can presume it is applicable for all environments.

Primary use case, SWT libraries, which has 32/64bit, windows/linux variants.

I specify the mainClass for my included JarResource, but I get the following warning at build time:

[INFO] -- Prepare jnlp files
[INFO] prepare jnlp org.codehaus.mojo.webstart.JnlpFile@59429fac
[WARNING] Something failed while checking if the main class contains the main() method. This is probably due to the limited classpath we have provided to the class loader. The specified main class (com.digitalsteps.lisa.client.LISAMainClient) found in the jar is *assumed* to contain a main method... com/digitalsteps/jaas/ILoginObserver

When I launch the jnlp file from my browser, it fails because it can't find a main() method in ILoginObserver, but this isn't the main class, I is not the one I specified. How can I correct this?

Thanks,

Allen

I was wondering if it is possible to sign jars with a hardware token. Since February 2017, GlobalSign only issues CodeSigning certificates with an eToken (USB). The problem with this, is that the signing configuration changes of the webstart-maven-plugin (to create a JNLP file). According to GlobalSign's website, the command for signing a jar with an eToken is as following (full article):

jarsigner -keystore NONE -storetype PKCS11 -tsa http://timestamp.globalsign.com/scripts/timestamp.dll -providerClass sun.security.pkcs11.SunPKCS11 -providerArg eToken.cfg test.jar "le-d0e453de-66db-414a-8fa8-0a07cfad66b5"

Converting this to pom.xml would make it the following:

<!-- SIGNING -->
<sign>
    <keystore>NONE</keystore>
    <storetype>PKCS11</storetype>
    <tsaLocation>http://timestamp.globalsign.com/scripts/timestamp.dll</tsaLocation>
    <providerClass>sun.security.pkcs11.SunPKCS11</providerClass>
    <providerArg>eToken.cfg</providerArg>
    <alias>le-d0e453de-66db-414a-8fa8-0a07cfad66b5</alias>
    <verify>true</verify>
</sign>

• tsaLocation: I got this one from the following issue: #11
• providerClass: not supported?
• providerArg: not supported?

As you can see, I need to configure a providerClass and providerArg to get the signing to work, is this already supported? I don't seem to find any information on it.

the maven content is:

`
true

                        <codebase>${application.url}</codebase>
                        <workDirectory>${application.directory}</workDirectory>
                        <!-- Set to true to exclude all transitive dependencies. Default is 
                            false. -->
                        <excludeTransitive>false</excludeTransitive>
                        <outputJarVersions>false</outputJarVersions>
                        <canUnsign>true</canUnsign>
                        <unsign>true</unsign> <!-- unsign already signed packages and sign them with own key -->

                        <unsignAlreadySignedJars>true</unsignAlreadySignedJars>
                        <verifyjar>true</verifyjar>
                        <makeArchive>false</makeArchive>

                        <libPath>libs</libPath>
                        <dependencies>
                            <!-- Note that only groupId and artifactId must be specified here. 
                                because of a limitation of the Include/ExcludesArtifactFilter -->
                            <includes>
                                <include>com.github.becausetesting:commons</include>
                                <include>com.jgoodies:jgoodies-common</include>
                                <include>com.jgoodies:jgoodies-looks</include>
                                <include>com.jgoodies:jgoodies-forms</include>
                                <include>com.miglayout:miglayout-core</include>
                                <include>com.miglayout:miglayout-swing</include>
                                <include>log4j:log4j</include>
                                <include>net.sourceforge.jtds:jtds</include>
                                <include>net.java.dev.jna:jna</include>
                                <include>net.java.dev.jna:jna-platform</include>
                            </includes>
                        </dependencies>
                        <sign>
                            <keystore>${application.directory}/KeyStore_${timestamp}</keystore>
                            <keypass>YourPassword</keypass>
                            <storepass>YourPassword</storepass>
                            <alias>WebStartJNLP</alias>
                            <storetype>jks</storetype>

                            <validity>3650</validity>

                            <dnameCn>Alter Hu</dnameCn>
                            <dnameOu>Becausetesting</dnameOu>
                            <dnameO>GitHub</dnameO>
                            <dnameL>Shanghai</dnameL>
                            <dnameSt>Shanghai</dnameSt>
                            <dnameC>US</dnameC>

                            <verify>true</verify>
                            <keystoreConfig>
                                <delete>true</delete>
                                <gen>true</gen>
                            </keystoreConfig>
                        </sign>
                        <jnlp>
                            <inputTemplate>template.vm</inputTemplate>
                            <version>1.0</version>
                            <spec>1.0+</spec>
                            <href>${application.jnlpname}</href>
                            <allPermissions>true</allPermissions>
                            <j2seVersion>1.6+</j2seVersion>
                            <offlineAllowed>true</offlineAllowed>
                            <outputFile>${application.jnlpname}</outputFile>
                            <mainClass>${application.mainclass}</mainClass>
                        </jnlp>


                    </configuration>

`

Then take to run the built jnlp file ,it shows below error.
JNLPException[category: Launch File Error : Exception: null : LaunchDesc: <jnlp spec="1.0+" codebase="http://localhost:9999/commons-window-jnlp/jnlp" href="launch.jnlp"> <information> <title>commons-window</title> <vendor>Alter Hu</vendor> <homepage href="https://github.com/becausetesting/commons-window"/> <description>A common libraries used for windows framework.</description> <description kind="short">A common libraries used for windows framework.</description> <description kind="one-line">A common libraries used for windows framework.</description> <description kind="tooltip">A common libraries used for windows framework.</description> <icon href="images/splash.png" width="48" kind="default"/> <icon kind="splash" href="images/splash.png" width="128" height="128"/> <shortcut online="true"> <desktop/> <menu submenu="commons-window"/> </shortcut> <offline-allowed/> </information> <security> <all-permissions/> </security> <update check="background" policy="always"/> <resources> <java version="1.6+" href="http://java.sun.com/products/autodl/j2se" java-vm-args="-ea" initial-heap-size="128m" max-heap-size="512m"/> <jar href="commons-window-1.0.0.jar" main="true"/> <jar href="libs/jgoodies-common-1.8.1.jar"/> <jar href="libs/jgoodies-looks-2.7.0.jar"/> <jar href="libs/jgoodies-forms-1.9.0.jar"/> <jar href="libs/miglayout-core-5.0.jar"/> <jar href="libs/miglayout-swing-5.0.jar"/> <jar href="libs/commons-1.1.0.jar"/> <jar href="libs/log4j-1.2.17.jar"/> <jar href="libs/jtds-1.3.1.jar"/> <jar href="libs/jna-4.1.0.jar"/> <jar href="libs/jna-platform-4.1.0.jar"/> </resources> <application-desc main-class="com.github.becausetesting.commonswindow.CommonsWindowSample" download="eager"/> </jnlp> ] at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResourcesHelper(Unknown Source) at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResources(Unknown Source) at com.sun.javaws.Launcher.prepareResources(Unknown Source) at com.sun.javaws.Launcher.prepareAllResources(Unknown Source) at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source) at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source) at com.sun.javaws.Launcher.launch(Unknown Source) at com.sun.javaws.Main.launchApp(Unknown Source) at com.sun.javaws.Main.continueInSecureThread(Unknown Source) at com.sun.javaws.Main.access$000(Unknown Source) at com.sun.javaws.Main$1.run(Unknown Source) at java.lang.Thread.run(Unknown Source)

goals.txt files are long being marked deprecated for maven-invoker-plugin.

Signing jars takes a lot of resources, so is there a way to not having to do this over and over (when performing mvn clean install)?
Having all jars signed before adding them to our artifactory might be one solution (or paying for enterprise edition?).

I'm thinking on having a cache with signed jars and a hash for the unsigned jar to find it, and then instead of signing, check the cache using a hash to see if there already is a signed version of the jar i'm about to sign. If there is no signed jar, sign it and cache it for the next time.
Is there a hook into the webstart-maven-plugin plugin where I can try to add this perhaps?
Perhaps easier to extend the actual plugin itself?

Any other creative ideas?

Sorry I tried looking it up but Codehaus is down so its hard to track down the actual threads. I am referring to this issue:
http://permalink.gmane.org/gmane.comp.java.maven-plugins.mojo.devel/40433

Is there a known workaround if not? The work around in this thread seems fairly manual which defeats the purpose of a generated JNLP

The Oracle Jdk7 is broken on container based trusty.

See Trusty with oraclejdk7, ends with: ERROR: JAVA_HOME is set to an invalid directory: /usr/lib/jvm/java-7-oracle #7884

While JAVA_HOME points to Jdk7, the actual executable java is set to Jdk8:

• java -version: 1.8.0_151
• JAVA_HOME: /usr/lib/jvm/java-7-oracle

Oracle Jdk8 and OpenJdk7 builds are still fine.

Build log (exceprt):

[…]
$ jdk_switcher use oraclejdk7
Switching to Oracle JDK7 (java-7-oracle), JAVA_HOME will be set to /usr/lib/jvm/java-7-oracle
update-java-alternatives: directory does not exist: /usr/lib/jvm/java-7-oracle
[…]
$ mvn clean verify -B -e -V
The JAVA_HOME environment variable is not defined correctly
This environment variable is needed to run this program
NB: JAVA_HOME should point to a JDK not a JRE
[…]

Travis.yml

language: java
sudo: false
install: true

jdk: 
  - openjdk7
  - oraclejdk7
  - oraclejdk8

script:
  - mvn clean verify -B -e -V

cache:
  directories:
    - '$HOME/.m2/repository'

branches:
    except:
        - gh-pages

notifications:
email: true

Workaround

Remove Oracle Jdk7 builds.

Hello,
I can't find a way to define the relation between packagespartsjar to enable the lazy loading mechanism of javaws. I need to add the following tags to configure eager- and lazy-loaded jars. The following example shows the declaration of an eager-loaded part:

<package name="org.tralala.*" part="eagerPart" recursive="true" />
<jar href="lib/org.tralala-2.2.3.jar" download="eager" part="eagerPart" />

Is it possible yet?

Hello.
Is it possible to create a jnlp-template.vm that accept dynamic arguments?
Thanks

I've finally got this wonderful plugin configured to create a JNLP file for my application.

I noticed that most of the elements under the <information> tag, like <offline-allowed>, and <homepage> are included by default.

Is there a way to configure the plugin to add an icon?

I've added the following to the default template,

...
#if($project.Description)
    <description>$project.Description</description>
#end
#if($icon.Href)
    <icon href="$icon.Href"/>
#end
#if($offlineAllowed)
    <offline-allowed/>
#end
...

But when I give that template to the plugin, I get
[ERROR] Failed to execute goal org.codehaus.mojo:webstart-maven-plugin:1.0-beta-7:jnlp-inline (default) on project purchase-order-arrivals: Unable to parse configuration of mojo org.codehaus.mojo:webstart-maven-plugin:1.0-beta-7:jnlp-inline for parameter icon: Cannot find 'icon' in class org.codehaus.mojo.webstart.JnlpConfig -> [Help 1]

I think I'm on the right track. I looked at the source and thought maybe it would need to be updated to support icons as well; if so, here's what I've managed so far: #51
Can anyone help?

See #21

From the document,
https://maven.apache.org/pom.html
There is following statement.
classifier:
The classifier allows to distinguish artifacts that were built from the same POM but differ in their content. It is some optional and arbitrary string that - if present - is appended to the artifact name just after the version number.
So, normally, when we use following dependency to get the dependency jar file, the name of the file is "wrapper-18.7.9-x64.jar"

           <dependency>
        <groupId>com.mat</groupId>
        <artifactId>wrapper</artifactId>
        <version>18.7.9</version>
        <classifier>x64</classifier>
    </dependency>

When use "webstart-maven-plugin 1.0-beta-4", the output jar is the same as original one "wrapper-18.7.9-x64.jar". But when use "webstart-maven-plugin 1.0-beta-6", the name of output jar changes to "wrapper-x64-18.7.9.jar". It brings us many difficulties.

The behavior is difficult with other plugin and is not the same as before.

The logic is in FullDependencyFilenameStrategy.java, and SimpleDependencyFilenameStrategy.java, We should move block " if ( StringUtils.isNotEmpty( artifact.getClassifier() ) )
{
filename += "-" + artifact.getClassifier();
}" to the bottom of this method.

public String getDependencyFileBasename( Artifact artifact, Boolean outputJarVersion, Boolean useUniqueVersions )
{
    String filename = artifact.getArtifactId();

   if ( StringUtils.isNotEmpty( artifact.getClassifier() ) )
    {
        filename += "-" + artifact.getClassifier();
    }

    if ( outputJarVersion != null )
    {

        if ( outputJarVersion )
        {
            filename += "__V";
        }
        else
        {
            filename += "-";
        }

        if ( useUniqueVersions != null && useUniqueVersions ) 
        {
            filename += artifact.getBaseVersion();
        }
        else 
        {
            filename += artifact.getVersion();
        }
    }


    return filename;
}

Hi,

There was the issues MWEBSTART-176 that proposed to include the generated JNLP file inside the main jar before signing it.

Is there any plan to implement that? I think that would be great, and it would combine very well with the need expressed in #12 !

Here is the previous content of the issue:

It would be very nice to have support for signing the JNLP file as part of the maven plugin. The installation appears more trustworthy for JNLP-signed applications. It can be done now, but it includes several error prone manual steps.

The signing process is really very simple. The final JNLP file should be included in the main jar file as /JNLP-INF/APPLICATION.JNLP before the jar file is signed.

I guess the following tasks have to be taken care of:

• Add support for a new configuration setting for the plugin in the pom file(boolean signJnlp)
• Add the new setting in AbstractBaseJnlpMojo.java or AbstractJnlpMojo.java with default value set to false
• Modify the execute() method in AbstractJnlpMojo.java so that the final JNLP file is generated before the main jar file is signed. For example move the call to generateJnlpFile( getWorkDirectory()) right after the call to processDependencies().
• Implement injection of the final JNLP file into the main jar file
  • Identify the main jar file and extract it
  • Copy the generated jnlp file to the extracted directory under /JNLP-INF/APPLICATION.JNLP
  • Create an new main jar archive with the modified content
  • Copy the main jar file into the lib location for further processing (packing and signing)

When using no codebase (1.6.0_u18+), the JNLP file should not be signed due to a bug in Java 6 and 7.

Even when no change has been detected to a jar (Do not reprocess ...), it is packed again when pack200 is enabled in the configuration.
There is no point to do so as nothing has changed.

It would be great if this implementation could be supported, since support for the native Pack200 implementation has been dropped from newer JDKs.

If you have a SNAPSHOT dependency, the filename in the war and the filename in version.xml does not match. As a result, WebStart can not download the file.

Example:
We have a dependency to jar sstl-util 1.11.0-SNAPSHOT

Filename in war/webstart: sstl-util-1.11.0-20150818.085702-5.jar

In version.xml:

  <resource>
    <pattern>
      <name>sstl-util.jar</name>
      <version-id>1.11.0-20150818.085702-5-20150821094500</version-id>
    </pattern>
    <file>sstl-util-1.11.0-SNAPSHOT.jar</file>
  </resource>

Should be:

  <resource>
    <pattern>
      <name>sstl-util.jar</name>
      <version-id>1.11.0-20150818.085702-5-20150821094500</version-id>
    </pattern>
    <file>sstl-util-1.11.0-20150818.085702-5.jar</file>
  </resource>

This has worked correctly in 1.0-beta-4, but does not work since 1.0-beta-5

I'm new to maven and I started to configure a previous version of webstart-maven-plugin
from http://www.mojohaus.org/webstart/webstart-maven-plugin/ but I need the features of that beta-8 snaphot, and I can't find it in a repo somewhere...

Anyone can help me (and probably add that to the FAQ on the web site ?)

If you a module (added to jarResource) has a dependency of type pom, the war does not include these dependencies.

Example: the module listed as jarResource has a dependency to

                <dependency>
                    <groupId>org.jboss.as</groupId>
                    <artifactId>jboss-as-ejb-client-bom</artifactId>
                    <type>pom</type>
                    <scope>compile</scope>
                </dependency>

In that case, dependencies listed in jboss-as-ejb-client-bom are not included in the war.

They were included in version 1.0-beta-4, but not in 1.0-beta-6 nor 1.0-beta-7-SNAPSHOT

It looks like the integration tests are expecting the jarsigner at a wrong / unexpected location ?

[debug] jarsigner executable=[/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre/bin/jarsigner]
[debug] Executing: /bin/sh -c cd /Users/kama/ws-git-codehaus/webstart/webstart-maven-plugin/target/it/it006/sign-one && /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre/bin/jarsigner -verify /Users/kama/ws-git-codehaus/webstart/webstart-maven-plugin/target/it/it006/sign-one/target/sign-one-1.0.jar
[warn] /bin/sh: /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre/bin/jarsigner: No such file or directory
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:

If you get a timeout from the timestamp server, then rather than failing the task, it only outputs a warning that you might need to set your proxy settings but leaves you with a corrupt jar file

I am trying to find a way to rename the jars once it is signed. I am using the version below.

<plugin>
	<groupId>org.codehaus.mojo</groupId>
        <artifactId>webstart-maven-plugin</artifactId>
	<version>1.0-beta-7</version>
	<executions>
		<execution>
			<id>generate-war</id>
			<phase>process-resources</phase>
			<goals>
			      <goal>jnlp-download-servlet</goal>
			</goals>

While Signing jars with pkcs12 http.proxyHost and http.proxyPort options are inserted multiple times during execution of jarsigner. Finally in one of iteration build will fail due to command length.

[DEBUG] Executing: cmd.exe /X /C ""C:\Program Files\Java\jdk1.7.0_80\jre\..\bin\jarsigner.exe" -verbose -keystore C:\repo\app\src\main\jnlp\app.pfx -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org -J-Dhttp.proxyPort=80 -J-Dhttp.proxyHost=some.address.org ...

<sign> <keystore>src/main/jnlp/app.pfx</keystore> <storepass>****</storepass> <storetype>pkcs12</storetype> <alias>app-alias</alias> <verify>true</verify> <tsaLocation>http://timestamp.digicert.com</tsaLocation> <httpProxyHost>some.address.org</httpProxyHost> <httpProxyPort>80</httpProxyPort> </sign>

[WARNING] The command line is too long. [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------

Hi there,

any chance we can get a release of 1.0-beta-7? I'm running into problems with the -SNAPSHOT version references that seems to have been fixed a year ago.

Let me know if I can help with the release! 😃

Thanks,
Andreas

cc @tchemit / @khmarbaise

I can see in the default template that there is a $arguments placeholder.

I've been looking around the source code, but can't figure out how to use it.

It sure would be dandy to be able to pass stuff into the <application-desc> tag, can anyone help?

As a note, with beta 3, if I ran this:

$ mvn clean cm-package:package

everything worked (sorry cm-package is a local plugin :| )

However with beta 7, I get a NPE

{{{
Caused by: java.lang.NullPointerException
at org.codehaus.mojo.webstart.util.DefaultArtifactUtil.artifactContainsClass(DefaultArtifactUtil.java:211)
at org.codehaus.mojo.webstart.JnlpDownloadServletMojo.resolveJarResources(JnlpDownloadServletMojo.java:490)
at org.codehaus.mojo.webstart.JnlpDownloadServletMojo.execute(JnlpDownloadServletMojo.java:180)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
}}}

full trace:
http://betterlogic.com/roger/2016/05/maven-webstart-plugin-woe/

This only fails when performed from a "parent" module, if run in the child it works OK. Just thought I'd report it.

If I set

<build>
    <finalName>foo</finalName>
    ...
</build>

in pom.xml and run mvn package, the zip file is renamed to target/foo.zip correctly. But the jar file in target/jnlp/... and in the zip archive keeps the default name of ${project.artifactId}-${project.version}.

I think it should also be renamed to finalName, or at least have an additional configuration option to rename it.

Hi,

hi have a plugin which modifie my maven-compiler-plugin output jar.
I wnat to sign this one but maven-webstart-plugin continues to take the original jar.

Can I specifie the path or the name of the jar to sign ?

thank you

For some reason jnlp-download-servlet tries to include com.sun.jmx:jmxri:jar:1.2.1 which it claims comes from log4j:log4j:jar:1.2.17 which does not have that dependency. Granted, log4j:log4j:jar:1.2.15 did have it and we DO have 1.2.15 in the dependency tree, but it's successfully managed to 1.2.17 as you can see below.
If jnlp-download-servlet is removed from the pom, the project compiles successfully. Project's dependency:tree does not have jmxri and no log4j specific sub-dependencies:

...
[INFO] |     +- log4j:log4j:jar:1.2.17:compile (version selected from constraint [1.2.16,))
[INFO] |     +- org.99soft.guice:rocoto:jar:6.2:compile
...

Plugin configuration

<plugin>
                        <groupId>org.codehaus.mojo</groupId>
                        <artifactId>webstart-maven-plugin</artifactId>
                        <executions>
                            <execution>
                                <phase>process-resources</phase>
                                <goals>
                                    <goal>jnlp-download-servlet</goal>
                                </goals>
                            </execution>
                        </executions>

                        <configuration>
                            <outputDirectoryName>webstart</outputDirectoryName>

                            <!-- Set to true to exclude all transitive dependencies. Default is
                            false. -->
                            <excludeTransitive>false</excludeTransitive>

                            <jnlpFiles>
                                <jnlpFile>
                                    <templateFilename>jnlpTemplate.vm</templateFilename>
                                    <outputFilename>launch.jnlp</outputFilename>
                                    <jarResources>
                                        <jarResource>
                                            <groupId>cm.ehjgdsfn.rt</groupId>
                                            <artifactId>ejt-trader</artifactId>
                                            <classifier>${cmehjgdsfn.config.env}</classifier>
                                            <version>${project.version}</version>
                                            <mainClass>com.bglw.gmrt.cmehjgdsfn.ejtrt.ejttrader.ejtTraderApp</mainClass>
                                        </jarResource>
                                    </jarResources>
                                </jnlpFile>
                            </jnlpFiles>

                            <sign>
                                <keystore>${basedir}/src/main/sign/keyStore</keystore>
                                <keypass>fdsrgqerg</keypass>
                                <storepass>fedfgwerg</storepass>
                                <alias>webstart</alias>
                                <verify>false</verify>
                            </sign>
                            <unsign>true</unsign>
                            <verifyjar>false</verifyjar>
                        </configuration>
                    </plugin>

Debug level maven build extract - section from the plugin running

[INFO] artifact log4j:log4j: checking for updates from cm-ehjgdsfn-repo
[DEBUG] Reading resolution-state from: /data/cmehjgdsfn/teamcity_home/agent2/m2-repo/log4j/log4j/resolver-status.properties
[DEBUG] Writing resolution-state to: /data/cmehjgdsfn/teamcity_home/agent2/m2-repo/log4j/log4j/resolver-status.properties
[INFO] artifact log4j:log4j: checking for updates from efs-repo
[DEBUG] Reading resolution-state from: /data/cmehjgdsfn/teamcity_home/agent2/m2-repo/log4j/log4j/resolver-status.properties
[DEBUG] Writing resolution-state to: /data/cmehjgdsfn/teamcity_home/agent2/m2-repo/log4j/log4j/resolver-status.properties
[INFO] artifact log4j:log4j: checking for updates from central-mirror
[DEBUG] Reading resolution-state from: /data/cmehjgdsfn/teamcity_home/agent2/m2-repo/log4j/log4j/resolver-status.properties
[DEBUG] Writing resolution-state to: /data/cmehjgdsfn/teamcity_home/agent2/m2-repo/log4j/log4j/resolver-status.properties
[DEBUG]       log4j:log4j:jar:1.2.17:compile (setting version to: 1.2.17 from range: [1.2.16,))
[DEBUG]       log4j:log4j:jar:1.2.17:compile (selected for compile)
[DEBUG]         javax.mail:mail:jar:1.4:compile (selected for compile)
[DEBUG]           javax.activation:activation:jar:1.1:compile (selected for compile)
[DEBUG]         com.sun.jdmk:jmxtools:jar:1.2.1:compile (selected for compile)
[DEBUG]         com.sun.jmx:jmxri:jar:1.2.1:compile (selected for compile)

Contents of /data/cmehjgdsfn/teamcity_home/agent2/m2-repo/log4j/log4j/1.2.17/log4j-1.2.17.pom are exactly the same as https://repo1.maven.org/maven2/log4j/log4j/1.2.17/log4j-1.2.17.pom.

Resulting error:

[10:19:14][Step 2/6] [ERROR] Failed to execute goal org.codehaus.mojo:webstart-maven-plugin:1.0-beta-6:jnlp-download-servlet (default) on project ejt-trader-webstart: Could not resolv transitive dependencies: Could not transfer artifact com.sun.jmx:jmxri:jar:1.2.1 from/to java.net (https://maven-repository.dev.java.net/nonav/repository): Cannot access https://maven-repository.dev.java.net/nonav/repository with type legacy using the available connector factories: BasicRepositoryConnectorFactory
[10:19:14][Step 2/6] [ERROR] com.sun.jmx:jmxri:jar:1.2.1
[10:19:14][Step 2/6] [ERROR]
[10:19:14][Step 2/6] [ERROR] from the specified remote repositories:
[10:19:14][Step 2/6] [ERROR] cm-ehjgdsfn-repo (http://choumvs149.amrs.win.mg.afg:8080/nexus-2.0/content/groups/public, releases=true, snapshots=true),
[10:19:14][Step 2/6] [ERROR] efs-repo (http://efs.worldnet.mg.afg/efs/dist/maven/maven2-repository/incr/common/lib, releases=true, snapshots=false),
[10:19:14][Step 2/6] [ERROR] central-mirror (http://choumvs149.amrs.win.mg.afg:8080/nexus-2.0/content/groups/public, releases=true, snapshots=false),
[10:19:14][Step 2/6] [ERROR] java.net (https://maven-repository.dev.java.net/nonav/repository, releases=true, snapshots=true)
[10:19:14][Step 2/6] [ERROR] Path to dependency:
[10:19:14][Step 2/6] [ERROR] 1) cm.ehjgdsfn.ejtrt:ejt-trader-webstart:war:1.52-SNAPSHOT
[10:19:14][Step 2/6] [ERROR] 2) cm.ehjgdsfn.ejtrt:ejt-trader:jar:1.52-SNAPSHOT
[10:19:14][Step 2/6] [ERROR] 3) ime:xa-server:jar:1.30.4
[10:19:14][Step 2/6] [ERROR] 4) log4j:log4j:jar:1.2.17
[10:19:14][Step 2/6] [ERROR] 5) com.sun.jmx:jmxri:jar:1.2.1: Cannot access https://maven-repository.dev.java.net/nonav/repository with type legacy using the available layout factories: Maven2RepositoryLayoutFactory: Unsupported repository layout legacy
[10:19:14][Step 2/6] [ERROR] -> [Help 1]

Hi,
The outputJarVersions parameter in configuration section is ignored.
If I set true or false the parameter outputJarVersions, the output of the jar resource in jnlp is :
<jar href="lib/commons-lang3.jar" version="3.6" />

if false, I'd like to have:
<jar href="lib/commons-lang3-3.6.jar" />

If your application is shaded, then you will be able to only keep your shaded jar. Pretty nice.

I would assume that the changes in pull request #42 will not completely address the issues at issue #6.

The fix seems to work for test jars produced by Maven 2, but not for timestamped snapshots, which have been introduced with Maven 3.

With Maven 3 the version.xml is right now:

  <resource>
    <pattern>
      <name>sstl-util.jar</name>
      <version-id>0.2.0-20230520.204741-2</version-id>
    </pattern>
    <file>sstl-util-0.2.0-SNAPSHOT.jar</file>
  </resource>

But it should be:

  <resource>
    <pattern>
      <name>sstl-util.jar</name>
      <version-id>0.2.0-20230520.204741-2</version-id>
    </pattern>
    <file>sstl-util-0.2.0-20230520.204741-2.jar</file>
  </resource>

The file name should be the real file (sstl-util-0.2.0-20230520.204741-2.jar) name and not constructed based on the artifact version (sstl-util-0.2.0-SNAPSHOT.jar) information.

The code has been changed (see VersionXmlGenerator) to support test files but now the timestamp based snapshots are no longer working.

Previously:

  writer.write( jarResource.getArtifact().getFile().getName() );

Actual:

writer.write( String.format( "%s-%s%s.%s", jarResource.getArtifactId(), jarResource.getVersion(), jarResource.getClassifier() == null ? "" : "-" + jarResource.getClassifier(), "test-jar".equals(jarResource.getType()) ? "jar" : jarResource.getType() ) );

With the actual code the issue regarding the timestamp based snapshots is still existing. The JNLP client will never find the file named sstl-util-0.2.0-SNAPSHOT.jar because it is sstl-util-0.2.0-20230520.204741-2.jar. This failure happens because the version in the pom is still 0.2.0-SNAPSHOT.

A valid maven-metadata.xml for a timestamp based snapshot artifacts which has been deployed twice would look like this:

<metadata>
    <groupId>unknown</groupId>
    <artifactId>sstl-util</artifactId>
    <version>0.2.0-SNAPSHOT</version>
    <versioning>
        <snapshot>
            <timestamp>20230520.204741</timestamp>
            <buildNumber>2</buildNumber>
        </snapshot>
        <lastUpdated>20230520204741</lastUpdated>
    </versioning>
    <snapshotVersions>
        <snapshotVersion>
            <extension>jar</extension>
            <value>20230520.194741-1</value>
            <updated>20230520194741</updated>
        </snapshotVersion>
        <snapshotVersion>
            <extension>jar</extension>
            <value>20230520.204741-2</value>
            <updated>20230520204741</updated>
        </snapshotVersion>
    </snapshotVersions>
</metadata>

I used the plugin with the version 1.0-beta-6.

Work around: Use the plugin setting "useUniqueVersions" with the config value "true", which leads the plugin to use Maven 2 snapshots without timestamps.

I know Webstart will disappear, but I want to see if I can compile and run with it under Java 9.

Is there parameters I should add to the java compiler so it can work ?

[INFO] --- webstart-maven-plugin:1.0-beta-7:jnlp (default) @ client ---

[WARNING] Error injecting: org.codehaus.mojo.webstart.sign.DefaultSignTool
java.lang.NoClassDefFoundError: Lorg/codehaus/mojo/keytool/KeyTool;
at java.base/java.lang.Class.getDeclaredFields0(Native Method)
at java.base/java.lang.Class.privateGetDeclaredFields(Class.java:3024)
at java.base/java.lang.Class.getDeclaredFields(Class.java:2205)
at com.google.inject.spi.InjectionPoint.getInjectionPoints(InjectionPoint.java:675)
...

Caused by: java.lang.ClassNotFoundException: org.codehaus.mojo.keytool.KeyTool
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
...

Caused by: java.lang.ClassNotFoundException: org.codehaus.mojo.keytool.KeyTool
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
...