Add support for getting classpath from kscript kts #235
Conversation
It acts pretty much like Maven, using most of the same resolution logic, but reads the targets from the script file with a prefix of "//DEPS ".
fwcd
added
the
dependency resolution
|
Any updates here? |
| .readLines() | ||
| .filter { artifactPattern.matches(it) } | ||
| .flatMap { it.substring("//DEPS ".length).split(",") } | ||
| .map { parseMavenArtifact(it) } |
There was a problem hiding this comment.
I'm a bit worried that this resolver is coupled too closely to Maven. What happens if e.g. a user uses Gradle instead? If we want to go this route, we might want to make it more generic, e.g. support different resolvers via //DEPS maven:..., gradle:... or even plain JARs.
Also I would probably go with a different prefix. //DEPS feels both a bit generic and magical at the same time. Perhaps we should mention the language server, i.e. something like
// kotlin-language-server: ...// kls-deps: ...// kls-classpath: ...
or similar. The last option would have the advantage of being consistent with our ShellClassPathResolver, which uses a file called kls-classpath to resolve the dependencies.
There was a problem hiding this comment.
I think the same, consider that kscript already resolves the dependencies, so I think kscript should be used to obtain the dependencies, the problem would be that kscript does not yet have an option to return the path of these dependencies, this PR adds this function but is pending merging.
As a test, I created a bash script to generate the kls-classpath file with this new feature of listing dependencies.
Another point would be the syntax of //DEPS is from kscript (or rather inherited from Jbang), but currently kscript has it deprecated, the currently recommended one would be this.
It acts pretty much like Maven, using most of the same resolution
logic, but reads the targets from the script file with a prefix of
"//DEPS ".