mvnw silently continues when no download mechanism is available (missing final else)

Locate the maven-wrapper 3.3.4 only-script template that emits mvnw and inspect the download dispatch around wget, curl, and set_java_home. Reproduce ./mvnw -v without those mechanisms, then verify the script reports the missing downloader before extraction instead of reaching unzip or tar.

Description

In the mvnw script generated by maven-wrapper 3.3.4 (distributionType=only-script), the download dispatch is a three-branch chain with no final else:

if [ -z "${MVNW_USERNAME-}" ] && command -v wget >/dev/null; then
  wget ... || die "wget: Failed to fetch $distributionUrl"
elif [ -z "${MVNW_USERNAME-}" ] && command -v curl >/dev/null; then
  curl ... || die "curl: Failed to fetch $distributionUrl"
elif set_java_home; then
  # compile and run Downloader.java
fi

If all three conditions are false — no wget, no curl, and set_java_home fails (no JAVA_HOME, no java/javac on PATH) — the block is a no-op. Execution continues, the SHA-256 validation block is skipped when distributionSha256Sum is unset, and the script then attempts to unzip/untar a file that was never downloaded.

The user sees an unzip/tar failure about a missing or corrupt archive rather than the actual cause, which is that no download mechanism was available.

Steps to reproduce

Run ./mvnw -v on a machine where wget and curl are absent from PATH, JAVA_HOME is unset, and neither java nor javac is on PATH, with no distribution yet cached under ${MAVEN_USER_HOME}/wrapper/dists.

Suggested fix

Add a final else that fails with a clear message, and/or assert the archive exists before extraction:

else
  die "No download mechanism available: install wget or curl, or make a JDK available on PATH / via JAVA_HOME"
fi

[ -f "$TMP_DOWNLOAD_DIR/$distributionUrlName" ] || die "Distribution was not downloaded: $distributionUrl"

Related question

The wget and curl branches are both gated on [ -z "${MVNW_USERNAME-}" ], so when MVNW_USERNAME is set they are skipped even if available, and the script always falls through to the Java downloader. Earlier jar-based wrapper scripts passed credentials directly (wget --http-user=… --http-password=…, curl --user …). If that is deliberate — because Downloader.java centralises auth via java.net.Authenticator — it may be worth a comment, since it means a machine with curl but no JDK cannot perform an authenticated download.

Environment

maven-wrapper 3.3.4, distributionType=only-script, Maven 3.9.16.