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 maven. For gradle, see this issue.
KLSP obtains Maven configuration by executing a couple of shell commands. Then it harvests and parses output to build classpath, sourceList, etc.
Why to change?
CLI is alwasys subject for sudden changes to command arguments format and output format. This is error prone approach. I, personally, faced a couple of issues with such architecture. The Maven CLI is not directly intended for usage by other programs. Maven has better means of integration with development tools.
Proper integration with Maven would not require to spawn a couple of system processes to obtain a configuration. This may potential improve startup times.
Implementation considerations
Unlike Gradle, Maven does not run as a daemon. It executes tasks per invocation and exits after completing them. Thus, we have nothing to connect with at runtime -- no inter-process communication happens. But, Maven provides classes to parse and build project configuration.
KLSP MUST load these classes into a process, in which KLSP runs.
Notice, that upon opening fresh project, project dependencies may not be synced. How to deal with that?
Rework existing Maven classpath resolver (shared/src/main/kotlin/org/javacs/kt/classpath/MavenClassPathResolver.kt) to use properly integrate with Maven according to Implementation Considerations.
Find out and describe in the comments bellow, how to invoke Maven targets with Maven Java API.
[x] Get to know Maven Object Model and core API classes
[x] Investigate, which useful data can be retrieved from Maven Project Configuration (for additional features. need your ideas on how this data can be useful)
[x] Make integration prototype (print sourcePath and classpath obtained from Maven Project Configuration. Test on at least two projects)
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 obtains Maven configuration by executing a couple of shell commands. Then it harvests and parses output to build classpath, sourceList, etc.
Why to change?
CLI is alwasys subject for sudden changes to command arguments format and output format. This is error prone approach. I, personally, faced a couple of issues with such architecture. The Maven CLI is not directly intended for usage by other programs. Maven has better means of integration with development tools.
Proper integration with Maven would not require to spawn a couple of system processes to obtain a configuration. This may potential improve startup times.
Implementation considerations
Unlike Gradle, Maven does not run as a daemon. It executes tasks per invocation and exits after completing them. Thus, we have nothing to connect with at runtime -- no inter-process communication happens. But, Maven provides classes to parse and build project configuration.
Notice, that upon opening fresh project, project dependencies may not be synced. How to deal with that?
Official Maven Javadoc: https://maven.apache.org/ref/3.9.9/apidocs/index.html
Potentially useful classes:
org.apache.maven.model.Model
org.apache.maven.project.MavenProject
org.apache.maven.model.io.xpp3.MavenXpp3Reader
Task
Rework existing Maven classpath resolver (
shared/src/main/kotlin/org/javacs/kt/classpath/MavenClassPathResolver.kt
) to use properly integrate with Maven according toImplementation Considerations
.Find out and describe in the comments bellow, how to invoke Maven targets with Maven Java API.