Us IntelliJ users would LOVE to see this getting fixed 
+1 for this to be fixed so auto-import can work.
+1 to get auto-import to actually work automatically.
Letting clients pass in a custom stdout and stderr and then not actually using the custom stdout or stderr for the output seems like a bug to me (why would you ever not want to use those custom output streams?)
This bug has been opened and blocking better integration with intellij (and other tools) for over a year. It doesn't sound like it's that hard of a thing to fix.
Is this something that the community could fix and then contribute as a patch?
Anything that help improves Intellij integration gets a +1 from me. The current level of integration is hampering migration of our code base to Gradle.
See also this related issue: http://forums.gradle.org/gradle/topics/gradle_tooling_api_produces_copious_log_output_that_is_difficult_impossible_to_suppress
+1 Is there any progress on this issue? This blocks a full IDEA integration, see http://confluence.jetbrains.com/display/IDEADEV/Gradle+integration
We would like to have this fixed for Grails 3 where we use Gradle extensively via the Tooling API.
I've been looking in to this issue and it seems that the problem is around these lines of code:
in org.gradle.tooling.internal.provider.ProviderConnection
and
in org.gradle.tooling.internal.provider.LoggingBridgingBuildActionExecuter
We'd also like to be able to do colored (ansi escaped) output in the tooling API so that the output is similar to the cli output. There has been a question about this on the gradle-dev mailing list.
The ansi output in tooling api isn't directly related to this issue, but I'll write some notes here since I didn't find a separate issue about the colored output with Tooling API.
I did a local spike and I was able to get "forced" colored output (ansi escaped) for the cli by changing the code around these lines of code:
ConsoleConfigureAction
protected ConsoleDetector createConsoleDetector(OperatingSystem operatingSystem) { if (useAnsiOutput) { return new ConsoleDetector() { public ConsoleMetaData getConsole() { return new FallbackConsoleMetaData(); } }; }
public void execute(OutputEventRenderer renderer) { ConsoleDetector consoleDetector = NativeServices.getInstance().get(ConsoleDetector.class); ConsoleMetaData consoleMetaData = consoleDetector.getConsole(); if (consoleMetaData == null) { return; } boolean stdOutIsTerminal = consoleMetaData.isStdOut(); boolean stdErrIsTerminal = consoleMetaData.isStdErr(); if (stdOutIsTerminal) { OutputStream originalStdOut = renderer.getOriginalStdOut(); PrintStream outStr = new PrintStream(useAnsiOutput ? originalStdOut : org.fusesource.jansi.AnsiConsole.wrapOutputStream(originalStdOut)); Console console = new AnsiConsole(outStr, outStr, renderer.getColourMap()); renderer.addConsole(console, true, stdErrIsTerminal, consoleMetaData); } else if (stdErrIsTerminal) { // Only stderr is connected to a terminal OutputStream originalStdErr = renderer.getOriginalStdErr(); PrintStream errStr = new PrintStream(useAnsiOutput ? originalStdErr : org.fusesource.jansi.AnsiConsole.wrapOutputStream(originalStdErr)); Console console = new AnsiConsole(errStr, errStr, renderer.getColourMap()); renderer.addConsole(console, false, true, consoleMetaData); } }
I'll try to find out if I can get the tooling API output to use "forced" colored output by using a similar config in LoggingBridgingBuildActionExecuter/ProviderConnection. I'm new to gradle source code so I'm just hacking around to see if something works. I hope that helps us all to get this issue solved faster. As I mentioned, we'd like to get the "forced" ansi colored output too for the tooling API output, not just a solution for redirecting stdout and stderr.
The "forced" ansi colored output requires skipping detection whether a real terminal is connected to stdout or not (both Gradle and Jansi do this). The windows OS detection should be skipped too (in Jansi), if we say we want ansi output, there shouldn't be any extra terminal or os detection magic. That's what I did with my small changes to get forced ansi escaped output in the cli. Something similar is required for the tooling api output if we want to get ansi escaped output there too.
Lari, this would be great. The single most important bug holding us back from building more tools on top of Gradle is this one. If you could fix the colors as well, that'd be even better.
I'm trying to understand the current solution and I'm writing some memos here about my investigation:
The reason why output of System.out/System.err isn't captured is because this row adds default output to System.out/System.err:
https://github.com/gradle/gradle/blob/b1e1d48866cb73b0a621142ca7444c8b22f9383a/subprojects/core/src/main/groovy/org/gradle/logging/LoggingServiceRegistry.java#L129
It would overriding the createOutputEventRenderer() method like LoggingServiceRegistry.CommandLineLogging class does to be able to control logging. Should probably implement "Action<? super OutputEventRenderer> consoleConfigureAction" like ConsoleConfigureAction that CommandLineLogging does.
I started hacking on some stuff https://github.com/lhotari/gradle/commits/ansi_support
I got the colored output working and I believe it also fixes this issue GRADLE-2687. I made a PR: https://github.com/gradle/gradle/pull/340
First changeset from that patch is integrated now. I' going to take a look at the next part to redirect the log messages too before the operation is started.
Any progress on this issue? It is impacting the development of Grails 3.0
Probably a reason mentioned by Lari also causes that messages printed directly on stdout/stderr cannot be tested/asserted with nebula-test (what was possible with Gradle 1.x).
As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.
We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.
Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:
- Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
- Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.
We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!
I believe this issue has been fixed with a Gradle 2.x release. I cannot reproduce the issue anymore with Gradle 3.3. Please open an issue on GitHub in case you are still running into issues.