Add ability to download jpackage tool

[msgilligan]

Rather than require that jpackage be preinstalled at a location specified by jpackageHome, it might make sense to add a task which will download a specified version of the pre-release jpackage build.

Maybe this could be done in one or more examples using an existing Gradle download plugin or perhaps it could be added directly to this plugin.

One issue is that existing download URLs on https://jdk.java.net/jpackage/ become 404s every time a new version is released.

[msgilligan]

@siordache I created this issue because I'm considering using one of the Gradle download tasks and trying to create a working example of how to do this without code changes to the BA JLink plugin. What do you think?

[siordache]

I updated the fxgl-sliding-puzzle to allow downloading the jpackage tool. You need to uncomment this line to enable the download.

EDIT: I made a small change in build.gradle. Now you need to set the system property download.jpackage to true in order to enable the download:

./gradlew -Ddownload.jpackage=true jpackage

I only tested on Windows. Please let me know if there are issues on other platforms.

[msgilligan]

@siordache I see you also added /Contents/Home to the macOS directory path! With that fix, it worked for me on macOS. I'm going to update to the property change you just made -- I'm using Github Actions, so I'll do just what you did with Travis and set -Ddownload.jpackage=true for the CI build.

[msgilligan]

Thanks for this, @siordache ! In my ConsensusJ fork of bitcoinj, I now have Github Actions building the "WalletTemplate" sample wallet app for macOS and Linux:

https://github.com/ConsensusJ/bitcoinj/commit/3997fd7d5377605c0188b19ed38d8451142e7b30/checks

I'm not building Windows right now because the bitcoinj unit tests are failing under Windows.

[msgilligan]

... and they just broke our links by bumping to:

Build 14-jpackage+1-49 (2019/10/2)

https://jdk.java.net/jpackage/

Also, the new tool uses --dest instead of --output so the plugin needs a change for that.

UPDATE:

I see there is a fix for --dest, here: https://github.com/beryx/badass-jlink-plugin/commit/fa611d8900ae5fbf0881f45d20aba6c811e3d52b

[msgilligan]

OK, so this approach is pretty brittle. Version 1-35 disappears and the new version has incompatible command-line options and won't work until an updated BA Jlink Plugin is released. It also looks like they've got changes coming that will require JDK 13 or later and Gradle 6 (the first version that supports JDK 13) isn't released yet.

I guess what I'll do for now is put the new 14-jpackage+1-49 version on my private S3 repo so that it won't disappear when a new version is released. And my builds can just be broken until the new BA Jlink Plugin is released.

[siordache]

I just released 2.16.0, which works with the new 14-jpackage+1-49.

[msgilligan]

OK, I have it working for my wallet-template builds: https://github.com/ConsensusJ/wallet-framework/commit/598e0132f024893e7d0a12ad8a2ff004426da199/checks?check_suite_id=249040212

But it is failing on unbuntu-latest running rpmbuild in the bitcoinj build: https://github.com/ConsensusJ/bitcoinj/runs/245735148

It looks like this is because rpmbuild doesn't like how it's called when jpackage is called with --app-version 0.16-SNAPSHOT

I have a workaround that should be good enough for now, but it might be nice if there were a better error message when this happens.

[siordache]

Replacing this line with:

appVersionForJpackage = version.replace('-', '.')

probably also works. It's still a workaround though.

[msgilligan]

So, building with the jpackage and download tasks has been working well for me until recently. Now, I'm getting the following failure on Windows:

FAILURE: Build failed with an exception.
324
> Configure project :omnij-wallet
325

326
Evaluating project ':omnij-wallet' using build file 'D:\a\wallet-framework\wallet-framework\omnij-wallet\build.gradle'.
327
* What went wrong:
328
Compiling build file 'D:\a\wallet-framework\wallet-framework\omnij-wallet\build.gradle' using SubsetScriptTransformer.
329
Task '.jpackage=true' not found in root project 'wallet-framework'.
330
Found module name 'omnijwallet'
331

It looks like something changed on Github, because the exact same repository state that worked before now fails. Does anyone have any ideas what might be causing this? (I realize this is probably more of a Github Actions issue than a Gradle BA JLink Plugin issue)

Here's a failed build: https://github.com/ConsensusJ/wallet-framework/runs/276993846 And here's my gradle.yml: https://github.com/ConsensusJ/wallet-framework/blob/msgilligan-0.1.5-maint/.github/workflows/gradle.yml

[siordache]

It's probably PowerShell's fault. Try to quote "download.jpackage" in this line:

run: ./gradlew -D"download.jpackage"=true buildCI consensusj-netwallet-fx:jpackage --info --stacktrace

[msgilligan]

Thanks @siordache , that did the trick! (I don't know what changed on Github's end to make this necessary after it was previously working without quotes. I think I need to get a local windows system for testing and to learn about PowerShell, etc.)

[msgilligan]

@siordache I've migrated an instance of my (yours, too) badass-jlink-plugin sample/template code upstream to the supernautfx-hello sample application subproject in the ConsensusJ/SupernautFX repository. (SupernautFX is a prototype minimal framework/library that enables using Micronaut Dependency Injection in a JavaFX application)

Other than the use of SupernautFX this "hello" application is much simpler than any of the bitcoinj-based apps that I've previously shared here. JPackage app builds for [LInux, macOS, Windows] x [JDK11, JDK13] are generated by Github Actions and available for download as Github Actions Artifacts.

One notable thing in the build.gradle for this subproject is the normalizeAppVersion () function. It still needs work and the comments include a link to the valid rules for the MSI productVersion string.