See: #37 (comment)

See: #74 (comment)

Android generates a lot of intermediate sources such as AIDL, Render script, C/CPP, etc. Unfortunately AGP doesn't provide any APIs to retrieve these files. R.jar is one of these intermediate sources which is crucial for Android development so as a workaround in #173 I have retrieved the file using the process task for the build variant however, in some cases the task may not be registered during the sync in which case the dependency for R.jar is not provided.

@jdneo I think Metals used debugSessionStart but for DebugSessionParamsDataKind used the same data kinds we use for tests e.g. scala-test-suites-selection and scala-test.

What's kind of interesting is that different clients might want different debug adapters....

Metals is primarily for Scala development so it uses https://github.com/scalacenter/scala-debug-adapter
For Kotlin there is https://github.com/fwcd/kotlin-debug-adapter
Java has https://github.com/microsoft/java-debug

I imagine the Java one is good enough for all but it would be handy to be able to specify the type in the BSP command and have the build server kick start the relevant one. Another thing to propose to add to BSP spec.

Originally posted by @Arthurm1 in #144 (comment)

The discussion was originally raised at #113 (comment)

What I do think is that this data might have to be cached. Have you tried the plugin on a big project? e.g. Gradle itself. It takes about a minute to respond to build/initialize (which I think should be instant and is slow because the source sets are queried in response to this request but not yet needed). Then, after a compile, the source sets are all queried again. It would be good to delay the building of the sourcesets until the client requests them and do they need to be built again after every compile?

See: #39 (comment)

See: #125 (comment)

Goal:

1. When it's writing, pending the reading.
2. When it's reading, pending the writing.
3. Reading can happen concurrently.

Android Components to be used by an Android project is configured via ANDROID_HOME environment variable. If the property doesn't exist then we are not providing the dependency in #173. This implementation can be improved via fallback logic similar to what we did for JAVA_HOME in #165

See: https://docs.gradle.org/current/userguide/test_kit.html#sub:gradle-runner-gradle-version

And the discussion in #149

This initiative will focus on adding support for all the Gradle Supported Languages that are currently unsupported.

There were recent initiatives for Kotlin, Groovy & Scala and this issue will focus on extending the support to other Gradle Supported Languages such as C/C++ and Javascript.

Related Links for more information :

https://gradle.github.io/community/events/gsoc/2024/gradle-build-server-devx/
https://gitlab.eclipse.org/eclipsefdn/emo-team/gsoc-at-the-ef/-/issues/5

The early version of protobuf Gradle plugin does not adds its generated java sources into the java source set. To make them be compiled correctly. The plugin add them as the input of the compileJava task. See:

https://github.com/google/protobuf-gradle-plugin/blob/3f28b0fc307293b86f267e71a7d1de9a8e564095/src/main/groovy/com/google/protobuf/gradle/ProtobufPlugin.groovy#L117-L119

Because the generated java files are not in the java source set, this makes some trouble to get all the source roots from the customized plugin. To mitigate this issue, one possible solution is to infer the source roots according to the input of the compileJava task:

project.getTasks().getByName("compileJava").getInputs()

And then find all the common ancestor folders - If the current file path does not belong to a source root. Get the source root according to the files package declaration, and add into the source root set.

See: #109 (review)

This error appears after we add #168 and #165

Need to figure out why it appears.

Client (IDEs) can use this information to determine if a source entry is optional or not.

Because if a source entry is included in the build directory, it may be removed by a clean action

The Cancellation in BSP is inherited from LSP. See:

build-server-protocol/build-server-protocol#524

Cancellation in LSP

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#cancelRequest
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#errorCodes

How LSP node client sending the cancel request

https://github.com/microsoft/vscode-languageserver-node/blob/f2ff7d55464a1f58f978cb6635bd8865f050553c/jsonrpc/src/common/connection.ts#L1398-L1412

See:

• build-server-for-gradle/server/src/main/java/com/microsoft/java/bs/core/internal/gradle/Utils.java

  Line 153 in a771284

  return "20";

• https://docs.gradle.org/8.5-rc-1/userguide/compatibility.html

This should address: microsoft/vscode-gradle#1420 (comment)

Today, the Gradle build server only supports pure Java project, while in the real world, Kotlin/Groovy/Android project may also be built by Gradle. So, we need to figure out a contribution point that allow different Gradle plugins to contribute their own build targets.

Migrate non-Open Source or non-External Collaboration repositories to GitHub inside Microsoft

In order to protect and secure Microsoft, private or internal repositories in GitHub for Open Source which are not related to open source projects or require collaboration with 3rd parties (customer, partners, etc.) must be migrated to GitHub inside Microsoft a.k.a GitHub Enterprise Cloud with Enterprise Managed User (GHEC EMU).

Action

✍️ Please RSVP to opt-in or opt-out of the migration to GitHub inside Microsoft.

❗Only users with admin permission in the repository are allowed to respond. Failure to provide a response will result to your repository getting automatically archived.🔒

Instructions

Reply with a comment on this issue containing one of the following optin or optout command options below.

✅ Opt-in to migrate

@gimsvc optin --date <target_migration_date in mm-dd-yyyy format>

Example: @gimsvc optin --date 03-15-2023

OR

❌ Opt-out of migration

@gimsvc optout --reason <staging|collaboration|delete|other>

Example: @gimsvc optout --reason staging

Options:

• staging : This repository will ship as Open Source or go public
• collaboration : Used for external or 3rd party collaboration with customers, partners, suppliers, etc.
• delete : This repository will be deleted because it is no longer needed.
• other : Other reasons not specified

Need more help? 🖐️

• Email [email protected]. ✉️
• Post your questions in GitHub inside Microsoft Team in Microsoft Teams. 🗨️

Sample project: https://github.com/puniverse/quasar

Workaround: Consider to use JavaCompile#getDestinationDir(): https://docs.gradle.org/current/javadoc/org/gradle/api/tasks/compile/AbstractCompile.html#getDestinationDir--, but this method will be removed in Gradle 9.0

See: #113 (comment)

The implementation here: https://github.com/microsoft/build-server-for-java/blob/554217567a39b3b2318ed95b6a964148f65c7c80/server/src/main/java/com/microsoft/java/bs/core/contrib/gradle/GradleBuild.java#L108 runs different tasks according to the sourceset. This is not efficient because of multiple connections are established to Gradle Daemon.

We should consider run required tasks in one time.

See: #37 (comment)

When client ask server for a non-exist build target, usually this is a hint that client and server is out-of-sync. We need to handle it smarter.

See: https://build-server-protocol.github.io/docs/specification#clean-cache-request

That means:

• incremental build: compile
• full build: clean + compile

It seems as of now, most of the javaDocs have been added just to prevent checkstyle warnings and does not provide the purpose of the given classes or methods clearly.

Since Gradle can run on Java 8 and so do some BSP clients, it would be good to build the plugin/server/model for java 8

Currently the project requires Java 17 but I think there are only a few instances of use of java syntax > version 8 and these could be easily changed.

Hey, I see that scala metals can use a custom BSP-compatible server (https://scalameta.org/metals/blog/2020/11/06/sbt-BSP-support/)

Is it possible to use build-server-for-gradle with metals?

I'd like to experiment with this project in combination with Scala Steward to extract dependencies from Gradle builds (scala-steward-org/scala-steward#2640). Other BSP server implementations provide a way to create BSP Connection Details so that BSP clients can launch the server easily. For example, connection details for bazel-bsp can be created with Coursier in a single command: cs launch org.jetbrains.bsp:bazel-bsp:<version> -M org.jetbrains.bsp.bazel.install.Install. For using BSP in Scala Steward I've collected how different build servers create connection details here. It would be nice if the Build Server for Gradle would also have a simple command to create connection details so that I can experiment with it in Scala Steward.

Then there is no need to do things like check checksums and copy the jar to a global storage.

The hooks seem to be there but it is currently unimplemented. We need to be able to delegate test and run execution to Gradle.

It seems from the blog is this is planned. Is there an ETA?

Full context can be found here: redhat-developer/vscode-java#3721

In short, simply check the compilation options may have some issue for some cases, An example is the project in the linked issue.

User can set the source level to 17, and target level to 8. Meanwhile, use [--release, 8] as the compilation arguments. Normally, this should fail during compilation. But the project uses a annotation processor to make it work.

Which says, maybe we should just simply get the source compatibility from the property, not infer it from the compilation options?

@Arthurm1, WDYT?

Including:

• the log level
• Enable/disable loggers

This repository is currently missing developer documentation to assist anyone trying to utilize Gradle Build Server.
This may contain:

• information about implemented features in GBS and their limitations (if any)
• steps for troubleshooting
• diagrams and examples

It's time to review and renew the intent of this repository

An owner or administrator of this repository has previously indicated that this repository can not be migrated to GitHub inside Microsoft because it is going public, open source, or it is used to collaborate with external parties (customers, partners, suppliers, etc.).

Action

👀 ✍️ In order to keep Microsoft secure, we require repository owners and administrators to review this repository and regularly renew the intent to either opt-in or opt-out of migration to GitHub inside Microsoft which is specifically intended for private or internal projects.

❗Only users with admin permission in the repository are allowed to respond. Failure to provide a response will result to your repository getting automatically archived. 🔒

Instructions

❌ Opt-out of migration

If this repository can not be migrated to GitHub inside Microsoft, you can opt-out of migration by replying with a comment on this issue containing one of the following optout command options below.

@gimsvc optout --reason <staging|collaboration|delete|other>

Example: @gimsvc optout --reason staging

Options:

• staging : My project will ship as Open Source
• collaboration : Used for external or 3rd party collaboration with customers, partners, suppliers, etc.
• delete : This repository will be deleted because it is no longer needed.
• other : Other reasons not specified

✅ Opt-in to migrate

If the circumstances of this repository has changed and you decide that you need to migrate, then you can specify the optin command below. For example, the repository is no longer going public, open source or require external collaboration.

@gimsvc optin --date <target_migration_date in mm-dd-yyyy format>

Example: @gimsvc optin --date 03-15-2023

Need more help? 🖐️

• Email [email protected]. ✉️
• Post your questions in GitHub inside Microsoft Team in Microsoft Teams.

We introduced the build action to solve composite build in #154. There is a problem that the build action class is in the server project, which is compiled by jdk 17. But in real, the build action class runs inside the gradle daemon, so if the gradle daemon is not running on jdk >= 17, error like Unsupported class file major version 61 will be thrown.

Looks like we should move GetSourceSetsAction into the model module.

I guess this is something we need to do before the parallel work @Arthurm1. I'll raise a PR soon.

In order to provide extensive feature support for Gradle Projects, we will enhance the Gradle Build Server by implementing all the necessary BSP requests that are currently unsupported.

BuildTargetRun
BuildTargetTest
DebugSessionStart
BuildTargetInverseSources

Related Links for more information :

https://gradle.github.io/community/events/gsoc/2024/gradle-build-server-devx/
https://gitlab.eclipse.org/eclipsefdn/emo-team/gsoc-at-the-ef/-/issues/5

My implementation in #173 takes into account any user defined build variants and the default build variants - debug and release except the default test variants - test and androidTest.

See:

See: #74 (comment)

Considering following log appenders.

1. file
2. telemetry
3. logMessage notification, client can decide how to print it, for example, the output channel.

There are various kinds of projects that come under Android development such as Application, Library, Instant App, Dynamic Modules, Android Test, etc. I have added support for the most commonly used projects - Application and Library in #173 but the current implementation may require further enhancements to support other kinds of projects.

Currently the definition of JvmBuildTarget is:

export interface JvmBuildTarget {
  /** Uri representing absolute path to jdk
   * For example: file:///usr/lib/jvm/java-8-openjdk-amd64 */
  javaHome?: URI;

  /** The java version this target is supposed to use.
   * For example: 1.8 */
  javaVersion?: string;
}

We can use javaHome to be the JDK path used to launch the project, and javaVersion to be the version of javaHome.

This implies that it is the server's responsibility to search the proper JDK to launch the Gradle daemon.

Based on that, add following fields:

• sourceCompatibility - source level
• targetCompatibility - target level

  Note that, sourceCompatibility and targetCompatibility might be different values so we can not use javaVersion to represent them both.

• compileArgs - arguments used for compilation.

@testforstephen WDYT?