Tell Gradle to shut up about its stupid daemon

The single-use daemon notification message irritates me greatly.
Every time I see it, I get worked up:

* I don't want my build system to leave a daemon process lying around
  post-build (what other build system does this, *especially* by default
  rather than opt in?), so I pass the --no-daemon flag to prevent that
  from happening.

* I don't care that another transient process is being forked -- other
  build systems like Maven do this all the time e.g. to invoke javac in
  its own process, and they don't spam the user about it. At minimum, I
  would expect there to be some kind of verbosity control, so that I can
  silence the message.

As such, I asked Claude whether it is possible to disable this message
by configuring Gradle's logger, and if not, how to go about modifying
the source code to add support for such a toggle. Here is what it said:

  ## Is it already configurable?

  Not in any targeted way. It is logged at Gradle's lifecycle level,
  which is the default level. The only existing knobs are the global
  log-level controls:

  - --quiet / -q on the CLI, or
  - org.gradle.logging.level=quiet in gradle.properties

  Any of those would hide the message — but they suppress all lifecycle
  output (including BUILD SUCCESSFUL, incubating-feature notices, etc.),
  so it's far too blunt. There is no per-message toggle for this
  specific line today.

  One important architectural fact that shapes the fix: this message is
  printed by the client/launcher JVM (SingleUseDaemonClient runs in the
  launcher, it's the thing that forks the daemon). That matters for
  where a system property is readable — see below.

  ## Recommendation

  Gradle itself already has a precedent for exactly this kind of
  opt-out: WelcomeMessageAction gates its output on the system property
  org.gradle.internal.launcher.welcomeMessageEnabled. I'd mirror that
  pattern. There are two levels of effort:

  ### Option A — minimal, one-file change

  Downgrade the message from lifecycle to info when a system property is
  set. In SingleUseDaemonClient.execute():

    String recommendation =
      documentationRegistry.getDocumentationRecommendationFor(
        "on this", "gradle_daemon", "sec:disabling_the_daemon");
    if (Boolean.getBoolean("org.gradle.daemon.singleUseMessage.disabled")) {
      LOGGER.info(MESSAGE + " {}", recommendation);
    } else {
      LOGGER.lifecycle(MESSAGE + " {}", recommendation);
    }

  Downgrading to info (rather than deleting the call) keeps the message
  discoverable with --info/--debug and preserves the existing
  SingleUseDaemonClientTest expectations if you run at info.

  Caveat on how you set it: because this runs in the launcher JVM,
  the property must be a real JVM system property of that process.
  That means one of:
  - gradle -Dorg.gradle.daemon.singleUseMessage.disabled=true …
  - export GRADLE_OPTS="-Dorg.gradle.daemon.singleUseMessage.disabled=true"

  A plain systemProp entry in gradle.properties will not work here —
  those are forwarded to the daemon JVM, not applied to the launcher.

  ### Option B — the "clean" Gradle-idiomatic way

  If you want it configurable via gradle.properties like
  org.gradle.welcome, thread a boolean down from
  BuildActionsFactory.runBuildInSingleUseDaemon (where DaemonParameters
  — which has parsed gradle.properties — is available) through
  DaemonClientFactory.createSingleUseDaemonClientServices →
  SingleUseDaemonClientServices → SingleUseDaemonClient. That's the
  properly-plumbed version and would let you use a real org.gradle.*
  build option, but it touches ~4 files and, to be a first-class option,
  ideally also a BuildOption subclass + serializer entry.

It is tempting to file a PR along the lines of Option A, but the fact
that it would then not work as expected via gradle.properties would
likely then bite people. Properly, the new option should also be added
to the documentation and ideally be part of the same PR.

So since -q already works to silence the warning, I just opted for that.
Sure, it silences a lot more than only the single-use daemon message,
but for this use case in pom-scijava, it doesn't matter. Good enough
for now, to keep me from having a micro-meltdown on every Maven build.

Now if I can just avoid ever noticing the irritating
  <!-- do_not_remove: published-with-gradle-metadata -->
comment line at the top of the POM...

See also:
- gradle/gradle#2660
- gradle/gradle#11517
- gradle/gradle#25272

Author: ctrueden

pom.xml

@@ -7273,6 +7273,7 @@
 									<executable>${gradle.wrapper}</executable>
 									<workingDirectory>${basedir}/gradle-scijava</workingDirectory>
 									<arguments>
+										<argument>-q</argument>
 										<argument>--no-daemon</argument>
 										<argument>--project-cache-dir</argument>
 										<argument>../target/gradle/build</argument>