Arguments were appended to the default task, so build.sh clean build ran
gradlew build clean build. Gradle folds that back into build and clean,
in that order, and the run ended by deleting the jar - with the script
then reporting the jar was missing, which was at least honest. The
README had claimed the invocation worked; nobody had run it.
A named task now replaces the default instead of being appended to it.
Flags are told apart from tasks by their leading dash, so --info still
gets a task to attach to rather than running gradlew with nothing to do.
The closing jar report is now conditional on a task that produces one
having run, since build.sh clean properly ends with no jar and should
not call that a failure.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A plain ./gradlew build fails outright on a machine whose default java
is newer than 23, which is now an ordinary thing for a distro to ship.
Gradle 8.12 cannot run there, and what it says about it is that it
could not create task ':test' because type T is not present - nothing
about Java, and nothing to act on.
build.sh picks a JDK between 17 and 23 and builds with that. JAVA_HOME
wins if it already points at a usable one, otherwise the openjdk paths
are tried in turn; if there is nothing to pick it says so and names the
range, rather than leaving the Gradle error to be decoded. Arguments
pass through, so it is a wrapper around the wrapper and not a second
way to describe the build.
It reports the jar by reading mod_id and mod_version out of
gradle.properties instead of listing build/libs, which keeps old
versions sitting in that directory from being mistaken for the build
that just ran.
The toolchain is untouched by any of this - the mod still compiles
against Java 21, whatever Gradle itself is running on.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Amir Alexander Abdelbaki