Use Output tab for Task - Gradle Server

[dhee9000]

Is your feature request related to a problem? Please describe.
Having the Gradle Server for this extension show up in the Terminal section of the bottom pane is somewhat annoying because I expect that space to be for terminals that I launch and use. Most extensions show their output under the Output tab of the same bottom pane. I believe that supports input too for use cases where the Gradle Task might need console input.

Describe the solution you'd like
It would be nice if the Gradle Server output could be shown in the output tab. If this isn't possible because the Output tab lacks a feature of the Terminal tab, at least have an option where users can toggle where it shows up. None of my Gradle tasks require user input so showing their output under Output if this was a restriction wouldn't be an issue.

Describe alternatives you've considered
None.

Additional context

• VSCode 1.46 (May 2020)
• Extension Version 3.3.0

[badsyntax]

Hi, thanks for the feature request. It looks like you are mentioning two things here:

1. The Gradle Server
2. Executed Gradle Tasks

In both cases, yes they are run in the terminal.

For the first case, I make the terminal visible so that users can see exceptions and stacktraces thrown by the server if there are any errors. I could potentially improve this, and hide the server terminal, and instead log everything to disk or to the output panel. This is something i'm willing to consider.

For the second case, the design of the extension is that Gradle tasks are run as vscode tasks. This is kinda the selling point of the extension: it creates VS Code tasks from the Gradle tasks (so you can, for example, use the "Run Task" command to run gradle tasks). VS Code tasks are run in an integrated terminal.

The output panel is meant for displaying simple text (like logs or errors), it cannot for example render color text as it does not support ANSI control characters.
There are other issues like interacting with the task process. For example, a gradle task might take a while to run. While it's run in the terminal, you can cancel the task as you would normally in a terminal (eg ctrl/cmd +c), but you couldn't do this in the output panel.

So you have to look at it as: extension output vs process output.

If I were to redirect output to the output panel, i'm not sure how I would manage the output channels. Does each task have it's own output channel? If so, the user cannot close/remove the channels, so you'll end up with a long list of output channels. Do you want all tasks to output to the same output channel? I think this might get confusing.

[dhee9000]

That makes sense, I guess it would make sense for Gradle Tasks to run in a terminal since they would run once I launch the corresponding VSCode task created by the extension. I thought about it and my only real issue was with having the initial Gradle Server output show up as a Terminal instead of in Output because it creates a Terminal as soon as I launch VSCode.

Like you said, I think separating the two separate parts here and moving (or offering the option to move) the Gradle Server output to the Output tab while keeping Gradle Task output in the Terminal tab (creating a Terminal when a task is launched) makes the most sense.

[badsyntax]

Cool, I'll make it so the "Task - Gradle Server" terminal is hidden by default, but users can show it via a setting 👍

(Somewhat related to #512, where the server shows the wrapper download status.)

[badsyntax]

dev notes: i spent a bit of time exploring the API. you can set task.isBackground but this does not hide the task terminal, so it's not possible to create tasks with hidden terminals AFAICT. i would need to start the server without using a vscode.Task and instead use the node apis.

[dhee9000]

Would using the node APIs and piping output to an Output Channel interfere with how the Gradle Tasks are run?

I'm not sure how this would work, I don't have much experience developing VSCode extensions but somewhere near GradleServer.ts:60 would have something like this I'm assuming?

let _channel: vscode.OutputChannel;
function getOutputChannel(): vscode.OutputChannel {
	if (!_channel) {
		_channel = vscode.window.createOutputChannel('Gradle Server');
	}
	return _channel;
}


const { stdout, stderr } = await exec(getGradleServerCommand(), { cwd });
if(stdout && stdout.length > 0) {
    getOutputChannel().appendLine(stdout);
}
if (stderr && stderr.length > 0) {
    getOutputChannel().appendLine(stderr);
    getOutputChannel().show(true);
}

// INSTEAD OF (DEPENDING ON USER SETTING)
// this.taskExecution = await vscode.tasks.executeTask(task);

[badsyntax]

Would using the node APIs and piping output to an Output Channel interfere with how the Gradle Tasks are run?

Nop! The output streams of the server are only related to the server itself (like logging or errors). Output streams of the Gradle Tasks are streamed to the client client via gRPC and rendered in the custom integrated terminal:

https://github.com/badsyntax/vscode-gradle/blob/82a3b403382a599754c07cf07a9b450d23393410/gradle-server/src/main/java/com/github/badsyntax/gradle/handlers/RunBuildHandler.java#L54-L71

So your example is on the right path, but as the server process is long running, we'd need to use cp.spawn and pipe the stderr and stdout streams to the output channel (probably using OutputChannel.append). I'm thinking to use the same "Gradle Tasks" output channel with a different prefix. So you would see logs similar to:

[info] [gradle-server] [main] INFO com.github.badsyntax.gradle.GradleServer - Server started, listening on 64258
[error] [gradle-server] [grpc-default-executor-3] ERROR com.github.badsyntax.gradle.handlers.RunBuildHandler - Could not execute build using Gradle distribution 'https://services.gradle.org/distributions/gradle-6.4-bin.zip'.

I'll probably adjust the Java log format to exclude redundant log levels (INFO,ERROR etc)

[badsyntax]

I've added some initial code with #540

[badsyntax]

I'm happy with #540 now, but this change could "break" things for users who have been relying on setting Gradle/Java ENV vars via terminal.integrated.env.*. Not sure what to do about that yet.

[badsyntax]

Sorry for the delay! Released with 3.4.0. Can you update the extension and test this change? Thanks!