Update Hatch Java / Javafx versions

This is how I tested in Linux. The same general procedures apply to Windows, assuming you fetch Windows binaries instead, of course, and manually install the JSON jar file.

The Hatch working branch applies a minor deprecation fix for jdk 11 and modifies hatch.sh and hatch.bat to look for the jdk 11 files in the local directory.

======
git clone git.evergreen-ils.org:Hatch.git
cd Hatch
git remote add working git.evergreen-ils.org:working/Hatch.git
git fetch working
git checkout -b user/berick/lp1817932-jdk11 working/user/berick/lp1741299-jdk11

wget https://download.java.net/java/GA/jdk11/9/GPL/openjdk-11.0.2_linux-x64_bin.tar.gz
wget https://download2.gluonhq.com/openjfx/11.0.2/openjfx-11.0.2_linux-x64_bin-sdk.zip
tar -zxf openjdk-11.0.2_linux-x64_bin.tar.gz
unzip openjfx-11.0.2_linux-x64_bin-sdk.zip

# hatch.sh assumes ./jdk-11 and ./javafx-sdk-11
mv jdk-11.0.2 jdk-11
mv javafx-sdk-11.0.2 javafx-sdk-11

./hatch.sh compile
./hatch.sh test
=====

Some questions:

1. Do we want to bundle Java and JavaFX binaries in with Hatch for deployment instead of requiring it be installed in advance? This gives us a lot of control and simplicity, but requires we monitor and create Hatch installer builds for java security updates.

2. Does the licence even allow bundling? I think so, but more eyes required.

From the download site:

"This page provides production-ready open-source builds of the Java Development Kit, version 11.0.2, an implementation of the Java SE 11.0.2 Platform under the GNU General Public License, version 2, with the Classpath Exception."

https://openjdk.java.net/legal/gplv2+ce.html

Note the OpenJFX files use the same license, but the builds are provided by a third-party. See https://openjfx.io/ for more.

The Windows builds I tested for reference:

curl -o jdk-11.zip https://download.java.net/java/GA/jdk11/9/GPL/openjdk-11.0.2_windows-x64_bin.zip
curl -o jfx-11.zip https://download2.gluonhq.com/openjfx/11.0.2/openjfx-11.0.2_windows-x64_bin-sdk.zip

Given how many lines of hatch.bat are just for cycling through all of the possible paths that Java may be hiding in and all of that nsi code that does the same, I'm 1000% for including everything you need in a single installer. (Especially if we can narrow down which jars we actually need vs "everything.")

Also, it would be better from the end user point of view if they only have to install 1 thing and they're done.

As far as licensing goes, since it's GPL2 + an exception I don't see where we would run into any issues since Hatch is also GPL2 and wouldn't even make use of the exception. (The purpose of which appears to be to allow you to link to GPL2 Java libs without also making your whole app GPL2.) I'm obviously no lawyer but that's how I read it.

Thanks, Jason.

It also occurs to me avoiding a proper Java install, where executables and libraries are made available to other applications, reduces exposure to potential Java security threats.

And there's the benefit of not preventing users from installing Java on their own if needed without concern for clobbering the version required by Hatch.

Bundling Java and JavaFX sounds like a fine idea. +1

You've got my +1!

I agree with Jason as far as licensing is concerned. I think this project is well within those considerations.

Getting started with a Linux script to fetch openjdk/openjfx/json Linux/Windows dependencies and put them in a well-known location within the Hatch directory. Also updates the hatch.sh and hatch.bat files to reference the new file paths.

https://git.evergreen-ils.org/?p=working/Hatch.git;a=shortlog;h=refs/heads/user/berick/lp1817932-jdk11

TODO:
 Update the windows exe builder and docs to accommodate these changes.

My branch noted above has additions from Kyle with my sign-offs. I also pushed another commit to tidy some of the installer bits/docs a bit more.

Note for now, the Windows installer documentation only has the from-Linux install steps in entirety since 1) we only have a Linux version of the new dependency fetcher and 2) I'm assuming for now that's the primary build environment for the Windows installer.

I have tested the new build on a Windows machine which does not have Java installed. It worked as expected and it's all very tidy.

As a general heads up, I was not able to find an appropriately licensed version of the Windows JRE by itself. Only the full JDK build for Windows is available from OpenJDK. (Ditto https://aws.amazon.com/corretto/). This means the Hatch installer contains the full JDK (which is a superset of the JRE). This puts the installer at ~225M in size.

I will upload a sample build to this bug shortly for further testing.

New installer built with version 0.3.0. Can be downloaded here:

https://evergreen-ils.org/downloads/Hatch-Installer-0.3.0.exe

FWIW, this one was built on Windows via the Linux subsystem. Works fine.

Additional commits pushed for more deps and docs cleanup and a separate commit to bump the Hatch version numbers from 0.2.0 to 0.3.0.

I have used this to circumvent the ERROR causing it to not even try printing the labels but I get several errors and the print fails. Works fine in the Printer Settings tester but not on the label printing page.

I presume more needs to be done for this?
It tries now but fails with the following console errors

core.bundle.js:1 No server setting type exists for cat.printlabels.last_settings, using local value.
c.handleServerItemResponse @ core.bundle.js:1
core.bundle.js:1 No server setting type exists for eg.print.template_context.item_label, using local value.
c.handleServerItemResponse @ core.bundle.js:1
core.bundle.js:1 No server setting type exists for eg.print.template.item_label, using local value.
c.handleServerItemResponse @ core.bundle.js:1
core.bundle.js:1 No server setting type exists for cat.printlabels.last_settings, using local value.
c.handleServerItemResponse @ core.bundle.js:1
core.bundle.js:1 No server setting type exists for eg.print.template.item_label_cn, using local value.
c.handleServerItemResponse @ core.bundle.js:1
core.bundle.js:1 No server setting type exists for eg.print.template.item_label, using local value.
c.handleServerItemResponse @ core.bundle.js:1
core.bundle.js:1 No server setting type exists for eg.print.template.item_label_cn, using local value.
c.handleServerItemResponse @ core.bundle.js:1
core.bundle.js:1 No server setting type exists for cat.printlabels.last_settings, using local value.
c.handleServerItemResponse @ core.bundle.js:1
core.bundle.js:1 No server setting type exists for eg.print.template_context.item_label, using local value.
c.handleServerItemResponse @ core.bundle.js:1
core.bundle.js:1 No server setting type exists for eg.print.template.item_label, using local value.
c.handleServerItemResponse @ core.bundle.js:1
core.bundle.js:1 No server setting type exists for eg.print.template_context.item_label, using local value.
c.handleServerItemResponse @ core.bundle.js:1
core.bundle.js:1 No server setting type exists for eg.print.last_printed
(anonymous) @ core.bundle.js:1

Just wanted to add this if it is of any use

Thanks, Christopher. The settings do need to be created -- some as workstation settings, some should be stored locally. I propose we open a separate LP for that. In my case, I was still able to print to a Dymo 330, regardless of the issues with the settings.

* I set the margins to HARDWARE_MINIMUM
* I set the correct paper type.
* When saving a spine label template, I had to save, close the tab, reopen the spine label print page and reapply the template before it would apply the desired changes.
* In my tests, I only printed the call number (no pocket labels) just to save paper -- the font would have to be tiny to fit both on the return address labels I was testing.

Related, I am also able to use the "Print" link for patron address printing. All I had to do there was modify the style in the patron_address template to fit all the text on the label:

<div style="font-size:.7em;">
....
</div>

Rebased branch to master and pushed another commit adding dependency fetcher support for "mac".

https://git.evergreen-ils.org/?p=working/Hatch.git;a=shortlog;h=refs/heads/user/berick/lp1817932-jdk11

Pushed one more commit with instructions for setting up Hatch on the Mac (INSTALL.adoc)