Or it should
Yes, cancel() from bsp4j worked fine for me.
I noticed that buildTargetCompile behaves differently from bloop compile. The former creates the class files in bloop-bsp-clients-classes/ and bloop-internal-classes/, whereas the latter uses the classpath specified in the JSON file.
When packaging modules, I will need access to the compiled classes. I presume I could include the ones from bloop-bsp-clients-classes/. Is there a better way?
Every BSP client has its own unique set of classes directories. You can obtain the unique classes directory for a target by asking for
buildTarget/scalacOptions of every target in the workspace right after the connection is initialized. Then, you can expect those directories to be populated when their corresponding targets are compiled.
WIP website for BSP https://olafurpg.github.io/bsp/index.html Comments welcome in scalacenter/bsp#102
Hi all, is there an initiative to add support for scala/dotty to https://che.eclipse.org (https://www.eclipse.org/che/docs/che-7/adding-support-for-a-new-language/), and is it the right place to talk about such integration ?
Hello, would it make sense to enrich the BSP with “presentation compiler” features? (such has request type information, completions, or inferred implicit parameters) I believe these features are necessary for building any Scala IDE so it seems to me that they should be part of the BSP.
@julienrf those features are part of LSP https://microsoft.github.io/language-server-protocol/specifications/specification-3-14/
It would be nice to bring to all Scala IDEs this very useful feature, which is currently only available in IntelliJ (and which is not using the actual compiler).
(it shows a call graph of the chained implicit definitions that have been inferred by the compiler)
Oops, did I just create a duplicate of scalameta/metals-feature-requests#21 (well, the feature request I’ve created has a smaller scope than this one, I would say…)
even if this was provided via bsp then it would require a fair amount of custom work to integrate it into IntelliJ.
I estimate it’s not too hard to implement in Metals with our existing decoration infrastructure
Need someone to pull up their sleeves and do the work however...
I can't figure out what's broken here https://travis-ci.org/build-server-protocol/build-server-protocol/builds/647315584?utm_source=github_status&utm_medium=notification I understand the
test -z $(git ls-files --modified) command is to check whether bsp4j/xtend was called by the user before commit, but on my PC it returns success
It seems that the release fails due to expired/invalid key https://travis-ci.org/build-server-protocol/build-server-protocol/
Hi, could you trigger https://travis-ci.org/build-server-protocol/build-server-protocol/builds/655697890 once more?
Hi, I opened a PR with
jvmRunEnvironment, which was a follow up of our discussions on jvmRunEnvironment when we decided, we want to have these two environment endpoints separate. In case if you'd like to merge them to a sigle jvmEnvironment instead, please just let me know.
The language server talks directly to the build server in our setup.
It’s still possible to implement an editor client for BSP, it depends on what your goal is.
Thanks :)
the repo should be a list of REST interfaces only and then the java thing is just one of many implementations
I think this is for similarity with the language server protocol specification: https://microsoft.github.io/language-server-protocol/specifications/specification-current/ However, I must say that I would rather see TypeScript interfaces instead of Scala interfaces, because it is not clear how Scala interfaces should be translated to JSON.
@julienrf the spec uses typescript interfaces https://build-server-protocol.github.io/docs/specification
there's no published npm package however
(ah, that was the case initially, that’s why I was confused! build-server-protocol/build-server-protocol@c0a91ef )
Do you know in that case what version of Scala should we give?