If I have the daemon enabled via a global property, and a project properties file that specifies a JVM argument that causes a fork to be required, for instance:
org.gradle.jvmargs=-XX:MaxPermSize=128M
When I run the build, with --no-daemon I see:
To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: https://docs.gradle.org/2.11/userguide/gradle_daemon.html.
Are you saying Gradle started a new daemon process with the JVM argument declare in the project properties even though you provided the command line args --no-daemon? Did you potentially already have this daemon running before?
It sounds like you’re concerned with an implementation detail that doesn’t have any effect on whether the functionality is working as intended.
If you specify JVM arguments that require forking, Gradle will fork a new JVM. Regardless of whether or not you want a daemon process, the class that runs is called GradleDaemon. The --no-daemon switch should cause the forked process to be single use instead of a long running daemon process, but it’s still going to run the GradleDaemon class.
If you can see the GradleDaemon process once that build completes, then that is a different issue, but not what you described.
That’s not quite what I see here, I don’t see any fork in the --no-daemon case, when there aren’t jvm options. The reason I run into this is I set GRADLE_OPTS to debug and profile, and GRADLE_OPTS obviously don’t apply to the 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 (jvmargs and daemon). It doesn’t matter how you have arrived at these values, either through defaults or explicitly setting/overriding the values. The next few values indicate whether a process with the java class name GradleMain or GradleDaemon will start when you start your build and die when your build completes. In these permutations, I’m ignoring the fact that a compatible daemon could already be running for simplicity (and because you said that there isn’t one in your case).
In both of your latest examples, you are specifying --no-daemon, so that’s the second and fourth row of the table. In your first example without JVM options (*), GradleMain will start, but GradleDaemon will not because there’s no need for it. In your second example with JVM options (**), GradleMain will start and GradleDaemon will start with the specified JVM options. This matches what you are showing in your running processes.
Your second line is the forked JVM with your specified JVM options. It is running GradleDaemon (the class), but it is not a daemon process. Once your build completes, both it and GradleMain will die. If you instead specified that you wanted the daemon (first row of the table), the GradleDaemon that you see would continue running as a daemon background after your build completed, and GradleMain died, waiting for the next GradleMain with compatible options to provide some work.