Hi!  Gradle doesn't like being invoked with /bin before /usr/bin in
PATH, and fails like this:

root@af57908f5326:/# PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
root@af57908f5326:/# gradle
/bin/gradle: 23: cd: can't cd to /bin/../share/gradle/bin/..
openjdk version "21.0.7" 2025-04-15
OpenJDK Runtime Environment (build 21.0.7+6-Debian-1)
OpenJDK 64-Bit Server VM (build 21.0.7+6-Debian-1, mixed mode, sharing)
Error: Could not find or load main class org.gradle.launcher.GradleMain
Caused by: java.lang.ClassNotFoundException: org.gradle.launcher.GradleMain
root@af57908f5326:/# echo $?
1
root@af57908f5326:/#

It would be nice if the 'gradle' wrapper script handle this situation
properly, and that it finds /usr/share/gradle properly in this
situation.

This is causing FTBFS of bookworm packages that use gradle during the
package build like 'testng7', 'opentest4j', 'opentest4j-reporting',
'picocli', 'libspring-java', 'jayway-jsonpath', 'mongo-java-driver', and
maybe some others.

/Simon

Hi Simon,

Nice catch. That's an interesting failure mode, probably another one
that was not completely anticipated by sponsors of /bin -> /usr/bin
directory aliasing, and it's likely to affect a number of projects using
wrapper scripts.

This is indeed a bug in the gradle package. My own build scripts are
always calling /usr/bin/gradle explicitly so they would not be impacted,
but it's definitely worth fixing as there is currently no easy way to do
that with debhelper's gradle buildsystem.

FTR, from the point of view of the upstream project Gradle isn't
supposed to be invoked with a command found through the PATH, and isn't
even supposed to be installed at a known place on any system. The
canonical way to use it is to run ./gradlew from the root of the project
you want to build (that is supposed to have a few bootstrap binaries
checked in along the project) and then let the thing happily download
the whole Internet to get the specific Gradle release(s), JDK(s) and all
the dependencies needed to build, run and test the project.

As official Debian packages can obviously not be built this way for
multiple good reasons, a package-specific default location is hardcoded
into the packaged Gradle so it can use that as a last resort to find its
installation root when the relative path guesses fail. We want to keep
the relative path mechanism as it's convenient for testing and using
multiple versions on a system.

Part of the issue is that the debhelper gradle class currently needs
gradle to be in the PATH and lacks a way to pass a different launcher
path. I'm also planning to fix that later.

Thank you for reporting this.

Cheers,