Goal

The main goal is to obtain robust project configuration directly from build systems. This allows to retrieve all required information to setup java's classpath, source path and compiler in general.

State of art

KLSP supports both maven and gradle. In this issue we focus on gradle. For maven, see this issue.

Classpath and dependency resolution code lays at shared folder of the project. Entry point is Home class. There are several adapters. They are structured in replaceable manner already. They all implement ClassPathResolver interface.

Currently, the list of source files is obtained via workaround. KLSP uses gradle-groovy scripts to list all classes. These scripts then send obtained information via stdout in custom format to the KLSP.

Look for scripts in shared/src/main/resources .

Why to change?

The current state of art is not acceptable. This is clearly a workaround. Gradle provides clear means of obtaining a build configuration. Scripts which are sending info through streams in a custom format are error prone, thus unreliable. Scripts are written in type-UNsafe language. They scrap information instead of querying it via intended means.

Implementation considerations

Gradle runs as a daemon -- long living process. We can query project configuration without any overhead: daemon starts, loads configuration; requesting the config is cheap.

Utilize Gradle Tooling API.

Gradle DSL model may be useful too: https://docs.gradle.org/current/dsl/index.html

Gradle Javadoc reference: https://docs.gradle.org/current/javadoc/index.html

Task

Implement Gradle Class Path ressolver, called GradleToolingClasspathResolver.

Kotlin-Language-Server / kotlin-language-server

Gradle build configuration #1

Goal

State of art

Why to change?

Implementation considerations

Task

Goals for 2024-09-17 meeting