Java WebStart and JNLP can be finicky beasts, especially when paired with Maven-generated websites and artifact repositories. Over the last few months I’ve developed POM and JNLP template patterns that I think are useful when used with the webstart-maven-plugin:jnlp goal; the main advantage is that applications can be WebStarted directly from the repository, which means that the version available is always the latest -SNAPSHOT
or release.
In the POM I define two variables, site.baseUrl
and artifactUrl
. site.baseUrl
defines the server and root path where all Maven-generated websites are published; it has a prefix because usually I’d only set it once in the corporate POM. artifactUrl
is the full URL of the project-specific website.
By default both site.baseUrl
and artifactUrl
point to the location where -SNAPSHOT
sites are published, usually by a CI system. They’re overridden in two profiles: release
switches site.baseUrl
to the release website (which is applied to artifactUrl
, so there’s no need to set it again), and devel
sets artifactUrl
to the local target directory (and omits site.baseUrl
, which ends up unused).
<project>
...<properties> <site.baseUrl>http://repository/snapshot-site/</site.baseUrl> <artifactUrl>${site.baseUrl}/${project.artifactId}</artifactUrl> </properties>
...<profiles> <profile> <id>release</id> <properties> <site.baseUrl>http://repository/release-site/</site.baseUrl> </properties> <distributionManagement> <site> <id>release-site</id> <url>dav:${artifactUrl}</url> </site> </distributionManagement> </profile> <profile> <id>devel</id> <properties> <artifactUrl>file://${project.build.directory}</artifactUrl> </properties> </profile> </profiles>
...</project>
In the JNLP template, the codebase
is set to artifactUrl
, which means that the resulting JNLP will retrieve any artifact dependencies from the snapshot, release or local output directories.
<jnlp spec="$jnlpspec" codebase="${artifactUrl}/jnlp/" version="$project.Version" >
...</jnlp>
Note that the artifact dependencies still need to be copied into the jnlp
directory, which webstart-maven-plugin:jnlp
does by default. It would be nice to be able to get them from their canonical locations on the repository, but that’s not easily accomplished.
About the last point – getting the artifacts from the repository, this possible with JFrog’s JavaFX plugin (APL v2) – http://wiki.jfrog.org/confluence/display/JP/JavaFX+Maven+Plugin
When using this plugin with the pro version of Artifactory, you also get all jars auto-signed on the repository with a server side key-pair, and you can serve them from Artifactory with a dynamically generated JNLP that includes repository-URLs for all resources. There is a demo of this here: http://wiki.jfrog.org/confluence/display/RTF/WebStart+and+Jar+Signing
I didn’t see a way that the JFrog plugin would let you point the jar resources directly to your repository when I tried it out; I see it can generate relative package-style URLs to the files within the codebase the same as the Codehaus plugin, e.g.
<jar href="com/example/artifact/artifact-1.1.jar"/>
, but what I was trying to accomplish was<jar href="http://repository/release/com/example/artifact/artifact-1.1.jar"/>
. (The demo doesn’t show that either; I don’t think it’s actually allowed.)I’d be hesitant to rely on specific repository software for the signing and JNLP; I like the content of my artifacts to be consistent before deployment and thus independent of the retrieval mechanism. In the right situation I can see it being handy though.
Just noticed a few instances where repository-specific paths slipped into the example; there’s nothing repository- or software-specific about the pattern, so I’ve excised them.