One-command installation of the ipmicli command (curl | sh, irm | iex) #163

Summary

With the CLI of #162, installing the IPMI client as a command-line tool means finding ipmi-java-x.y.z-standalone.jar on the GitHub release page and typing java -jar ... every time. ipmitool and ipmiutil are plain executables on the PATH; ipmicli should be as easy to install and to invoke. Jawk solved this with one-command installers (jawkio/jawk#583): do the same.

Proposal

One-command installers served from the documentation site (published with the Maven site from src/site/resources):

$ curl -fsSL https://metricshub.org/ipmi-java/get | sh

on Linux and macOS, and

irm https://metricshub.org/ipmi-java/get.ps1 | iex

on Windows. The installer downloads the standalone jar of the latest release, verifies its SHA-256 checksum, and puts an ipmicli launcher on the PATH. The launcher finds a Java runtime (8 or later) at run time and runs java -jar with the user's arguments, so installing or upgrading Java later needs no reinstall.

$ ipmicli -h bmc.example.com probe
$ ipmicli -h bmc.example.com -u monitor sensors

Suggested implementation

Port Jawk's src/site/resources/get, get.ps1 and .github/workflows/installers.yml, renamed:

• Release assets. Each GitHub release also gets a version-less ipmi-java-standalone.jar alias and .sha256 checksums of both jars, so that https://github.com/metricshub/ipmi-java/releases/latest/download/ipmi-java-standalone.jar is a stable URL that needs no API call. The release runs the shared metricshub/workflows maven-central-release.yml, which uploads target/*.jar only: either add a job after it in release.yml (download the versioned jar from the release, create the alias and the checksums, upload them), or add the option to the shared workflow, which winrm-java's standalone jar would use too.
• get (POSIX sh). Installs the jar under ${XDG_DATA_HOME:-~/.local/share}/ipmicli/ and the launcher in ~/.local/bin (no sudo); warns with the exact PATH line when ~/.local/bin is not on the PATH. IPMICLI_VERSION=x.y.z pins a release, IPMICLI_INSTALL_DIR changes where the launcher goes.
• Launcher. Looks for Java in $IPMICLI_JAVA_HOME, $JAVA_HOME, java on the PATH, /usr/libexec/java_home on macOS, then the usual JVM roots (/usr/lib/jvm, sdkman); rejects a runtime older than 8; without one, prints a clear message pointing to https://adoptium.net and exits non-zero. It exports IPMICLI_PROGRAM_NAME, so that ipmicli --help shows ipmicli ... and not java -jar ... (jawk -h prints its usage as java -jar jawk-standalone.jar, not jawk jawkio/jawk#591).
• get.ps1 (PowerShell). Installs under %LOCALAPPDATA%\ipmicli with an ipmicli.cmd shim and adds the shim directory to the user PATH.
• Installer smoke tests. A workflow runs both installers against the latest real release, on pull requests that touch them and weekly, as Jawk's installers.yml does.

Documentation

installation.md and the CLI page lead with the one-command installation (tabs for Linux/macOS and Windows, then "inspect the script before running it", then the manual download); the README CLI section too. The examples of the CLI page use ipmicli instead of java -jar ....

Acceptance criteria

• On a clean Linux, macOS and Windows machine with Java 8 or later, the one-liner installs ipmicli, and ipmicli --version prints the release version.
• IPMICLI_VERSION installs a pinned release; re-running the installer upgrades in place.
• A checksum mismatch aborts the installation without touching an existing installation.
• Without Java, the launcher fails with the documented message.
• The smoke-test workflow passes.

Follow-up of #162.