How to debug test cases with JDB and gradle?

[4EverEndeavor (Eric Berger)]

I actually do think this is related to gradle. From what I can tell, when trying to run gradle in debug mode using the above commands, the jdb cannot attach to a currently running daemon. Thomas Keller mentioned in this article:
https://www.thomaskeller.biz/blog/2020/11/17/debugging-with-gradle/
that running with the --no-daemon option fixes this. That at least gets us to where jdb is attached to the gradle launcher daemon. However, the actual process that I’m trying to debug is being spun off on a forked daemon with the following message:
To honour the JVM settings for this build a single-use Daemon process will be forked.
Details on that are here:

--no-daemon switch ineffective if JVM settings cause new fork

There’s four permutations of the two relevant settings here. I only directly addressed the two permutations that were covered in the original post which was whether the daemon options were behaving correctly when there are JVM arguments. You’re not seeing anything different with the added examples, but just now including additional permutations for without JVM arguments. So for completeness, we can look at all of them. The below table indicates a true/false value for the two relevant variables …

I can see both daemons:

$ ps -ef | grep Gradle
  502 89026 89024   0 10:46AM ttys001    0:03.18 java -Xmx64m -Xms64m -Dorg.gradle.appname=gradle -classpath /path/to/gradle/gradle-launcher-7.6.jar org.gradle.launcher.GradleMain project-name:test -Dorg.gradle.debug=true --no-daemon --no-build-cache --debug --tests fully.qualified.ClassName
  502 89072 89026   0 10:46AM ttys001    0:00.15 /Library/Java/JavaVirtualMachines/amazon-corretto-17.jdk/Contents/Home/bin/java --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.prefs/java.util.prefs=ALL-UNNAMED --add-opens=java.base/java.nio.charset=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED -XX:MaxMetaspaceSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xms256m -Xmx512m -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005 -cp /Users/eric/.sdkman/candidates/gradle/7.6/lib/gradle-launcher-7.6.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 7.6

In this, we can see that 89026 spawned 89072. I can also verify that 89072 is listening on the intended port.

lsof -i TCP:5005    
COMMAND   PID USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
java    89072 user    5u  IPv4 0x59f2cac75b000023      0t0  TCP localhost:avt-profile-2 (LISTEN)

What is think is happening here, is the child process does not have the debug mode set. When doing “run” from jdb, the correct test will execute, but no breakpoints will be honored, because it does not appear to be in debug mode.

I guess my real question is, how can I ensure the forked daemon in this case is actually in debug mode?
or,
How can I ensure I’m actually connecting to the forked daemon, and not just the parent process?