This isn't as hard as I imagined it would be, as we actually have a
Component reference in the appropriate method.
This fixes the fixed size HD client in a maximized window.
A previous commit accidentally renamed platformInfo field in a DSI
struct field access to platform_info. It was only intended to rename the
platformInfo local variable to fit in with the naming scheme.
This mirrors the change in the main OpenRS2 repository. I think the
natives actually work all the way back to Java 6 (or maybe even
earlier). However, we're only routinely testing the build against JDK11
(plus legacy Java 6 on macOS).
This isn't perfect as the compiled .so files use a mixture of /usr/lib
and /nix/store paths. It'd be nice if we could figure out how to make
them use /usr/lib paths only, such that it can be used to build the
natives for other distributions.
However, even though it isn't suitable for building releases, it does
allow us to test changes to the natives on NixOS.
The previous profile-based logic didn't work on Java 8 due to the
architecture-specific lib directories. It was also complicated by the
fact that nar.javaHome isn't set at profile activation time unless the
user manually specifies it with -D on the Maven command line.
This commit replaces it with an Ant task that runs during the
initialization phase. It finds the first (and probably only) jawt
library with glob matching, allowing us to search architecture-specific
lib directories.
If found, it strips the file name to get just the directory name and
sets openrs2.jawtProperty. If not found, it makes the build fail.
I haven't tested on 7 (and I'm not sure if the jawt shared lib files are
even in the correct place), so I think it's better to require the
version I've been testing on.
This is also consistent with the requirement for the main openrs2
project.
We need to enable all of the OS-specific profiles so the version numbers
of all the modules are bumped.
In turn this means we need to avoid calling the verify target during
release:prepare, as we can't build all the modules on any platform.
Similarly, we can't actually call the deploy target during
release:perform. We instead call `mvn -Prelease deploy` on each
supported operating system/architecture manually.
