Capture gradle stderr and stacktrace in SignalR Java client builds

[lewing]

Problem

When the SignalR Java client gradle build fails on CI (e.g. signalr.client.java.core.javaproj compileJava task), the only signal that reaches the binlog and AzDO timeline is MSB3073 reporting the gradle exit code:

error MSB3073: The command "../gradlew  -Dorg.gradle.daemon=false compileJava" exited with code 1.

Gradle's actual diagnostic output (* What went wrong, the javac error: lines, Caused by stack frames, etc.) is written to stderr but is logged at default importance, so it doesn't appear in the captured logs. The full gradle output we get in the binlog today for a failed run is literally:

> Task :core:generateVersionClass
> Task :core:compileJava
FAILURE: Build failed with an exception.

That makes every compileJava flake undebuggable without a re-run and leaves the failure signature too generic to file as a Known Build Error (since a regex on MSB3073 ... gradlew compileJava would silently match real Java-client regressions too).

Concrete instance found while triaging cross-PR CI noise: PR #66919 build 1448390 hit this on the Test: Windows Server x64 leg with no visible cause despite a complete binlog being archived.

Fix

Two small, low-risk changes:

• eng/targets/Java.Common.props: append --stacktrace --console=plain to GradleOptions when $(ContinuousIntegrationBuild) == true.
  • --stacktrace makes gradle print the full exception on failure.
  • --console=plain keeps output line-oriented (no ANSI escapes, no overwritten progress lines, which is what we want in archived CI logs).
• eng/targets/Java.Common.targets: set StandardErrorImportance="High" on the two Exec invocations of gradlew (the compileJava build step and the publishToMavenLocal pack step) so stderr flows through MSBuild at high importance and is captured in the binlog/console.

Behavior preserved

• Local non-CI builds are unaffected — the props change is gated on $(ContinuousIntegrationBuild) == true.
• The exit code still drives task failure exactly as before; MSB3073 will still be emitted on a non-zero gradle exit.
• javac's canonical path:line: error: lines remain eligible for MSBuild's built-in error/warning classification because IgnoreStandardErrorWarningFormat is left at its default (false).

Why now

Diagnosed during a sweep of recent aspnetcore-ci PR-build failures. Of ~18 failed builds sampled, only one (#66919, 1448390) hit this specific gradle failure, but the diagnostic gap means future occurrences (and any related flake we should be quarantining or known-issue-tagging) cannot be triaged from the archived logs alone. Adding the stderr capture is a one-time "never lose the trail again" investment that costs nothing on success.

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

[Copilot]

Pull request overview

Improves CI diagnostics for SignalR’s Java client Gradle builds by ensuring Gradle failure details (notably stderr output and exception stack traces) are visible in MSBuild-captured logs (binlog and CI console), making intermittent compileJava failures debuggable from archived artifacts.

Changes:

• Elevate Gradle stderr logging to high importance for the Java build and pack (publishToMavenLocal) steps so it’s captured reliably in CI logs.
• On CI only, append --stacktrace --console=plain to Gradle invocation options to produce actionable, line-oriented failure output.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
eng/targets/Java.Common.targets	Logs Gradle stderr at high importance for build/pack Exec steps so CI captures diagnostic output.
eng/targets/Java.Common.props	Adds CI-only Gradle flags to emit stack traces and plain console output for better failure diagnostics.