mojohaus / webstart Goto Github PK
View Code? Open in Web Editor NEWHome Page: https://www.mojohaus.org/webstart/
License: MIT License
Home Page: https://www.mojohaus.org/webstart/
License: MIT License
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>
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,
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
orAbstractJnlpMojo.java
with default value set to false- Modify the
execute()
method inAbstractJnlpMojo.java
so that the final JNLP file is generated before the main jar file is signed. For example move the call togenerateJnlpFile( getWorkDirectory())
right after the call toprocessDependencies()
.- 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.
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 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)
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] ------------------------------------------------------------------------
If your application is shaded, then you will be able to only keep your shaded jar. Pretty nice.
It would be great if this implementation could be supported, since support for the native Pack200 implementation has been dropped from newer JDKs.
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 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
Could we get a release so that I could not have bug #6 ? Or is this project really just dead?
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.
See #21
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
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:
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
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
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'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?
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
Hi, we are soon to be forced to use a hw token when current cert runs out mid july. We have not used hw token before.
We currently use this Maven Webstart plugin (Beta 7) for our Java 8 webstart program,
building manually including signing with a ' mvn ...' command from windows cli.
I see that there is a patch with Token code, submitted to the plugin already.
Please. Could someone help us getting to run on the patched version, it would be a very very big help.
I cannot find it in Maven repositories.
I saw that there is a Javafx-maven-plugin that has hw token code, but not being an expert I don't know if it's possible to replace the webstart plugin in my pom.xml with this javafx-maven-plugin with few changes. We don't use Javafx as such, only standard Java 8 code, building to run standalone swing app via JNLP (now Open).
I'm only the maintainer, not the that created our pom.xml originally.
Any ideas?
Thanks Michael
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)
...
goals.txt
files are long being marked deprecated for maven-invoker-plugin.
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,
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
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.
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?
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 ?)
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?
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 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.
Hello.
Is it possible to create a jnlp-template.vm that accept dynamic arguments?
Thanks
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.
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>
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.
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.
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?
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
The Oracle Jdk7 is broken on container based trusty.
While JAVA_HOME points to Jdk7, the actual executable java is set to Jdk8:
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.
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]
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.
Maybe it's time to change version naming from "1.0-beta-8" to "1.0.8"?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.