Consider publishing gradle build server to maven central

[jdneo]

See: #113 (comment)

[fthomas]

This would also help with #115.

[jdneo]

Hi @Arthurm1,

Is there any work that you want to be done before publishing to maven? I hope the first bit can be something that you can use to integrate into metals.

[Arthurm1]

@jdneo It would be great if you can publish it as it is now. I can then spend some time integrating it with Metals and fixing a couple of issues I know of.

At this point I doubt the average Metals user would use the Gradle server with Metals (over the current way of using Gradle via Bloop) because Metals relies on the BSP server to produce all the errors/warnings. So the user would get nothing in the Problems area of VSCode until this is added. I have a PR for this and could submit it but it wouldn't report correctly until the point I've raised in #116 (comment) is fixed.

#116 and #124 would be great to add but aren't essential for first version.

The Kotlin and Groovy stuff isn't used by Metals.

Metals releases beta versions quite often so it should be quick to try out new versions of build-server-for-gradle whenever they are released.

[jdneo]

@Arthurm1 I see. Thank you for the declaration. Since there are so many changes added comparing the one that is now embedded in the vscode-gradle extension. I'll first let the test team on our side do some smoke test recently. If everything works fine, I'll schedule a release (and I need some time to figure out how to publish to maven).

Thank you.

[jdneo]

@Arthurm1 May I ask how would you use the published jar in the integration?

Is that expected to be a single fat jar? Or the jar with only gradle build server itself, then you deal with the classpath when you launch it?

[Arthurm1]

@jdneo I'm no expert on publishing but I think just the server jar should be fine, with the dependencies in the POM file.

e.g. see the BSP4j pom here and the listed dependencies on org.eclipse.lsp4j:org.eclipse.lsp4j.generator:0.20.1 and org.eclipse.lsp4j:org.eclipse.lsp4j.jsonrpc:0.20.1

I think we'd also want the plugin com.microsoft.java.bs.gradle.plugin.GradleBuildServerPlugin published to Gradle plugins. Then it can be included in an initscript without specifying a classpath like it currently is here.
The Launcher #PROP_PLUGIN_DIR maybe could be changed to Launcher#INIT_SCRIPT_LOCATION to be more correct as it seems to only be used for that and the plugin.jar doesn't have to be in that dir. Although it might be better to create the init-script.gradle file in the temp dir on the fly and then this property can be removed completely.

[jdneo]

I think just the server jar should be fine, with the dependencies in the POM file.

I see. Then the build server will be used as a dependency, which can be launched by directly invoking its main class. Maven will help to resolve its runtime dependencies. Makes sense.