Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade language server version #89

Merged
merged 3 commits into from
Aug 1, 2024
Merged

Conversation

milesziemer
Copy link
Contributor

To go along with the changes in the language server 0.4.0: https://github.com/smithy-lang/smithy-language-server/blob/main/CHANGELOG.md#040-2024-07-30, this commit also:

  • updates coursier to use java 21 to run the server
  • adds config options diagnostics.minimumSeverity, onlyReloadOnSave
  • removes config option for logToFile

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

To go along with the changes in the language server 0.4.0:
https://github.com/smithy-lang/smithy-language-server/blob/main/CHANGELOG.md#040-2024-07-30,
this commit also:
- updates coursier to use java 21 to run the server
- adds config options diagnostics.minimumSeverity, onlyReloadOnSave
- removes config option for logToFile
@milesziemer milesziemer requested a review from a team as a code owner July 30, 2024 17:47
@milesziemer
Copy link
Contributor Author

Need to fix these failing tests

Most of the test suites read the old .smithy.lsp.log file that the
language server could be configured to write out. Since that was
removed, we need a different way to do test assertions. I tried to
see if we could look at the trace of messages between server <->
vscode client, but wasn't able to find a way. So I simplified the
assertions for these test suites, which should be ok because we
probably don't want to rely on logs anyways for testing, and more
robust testing is done on the server side (our extension doesn't
have that much functionality to test).

I also had to add `sources` to each of the smithy-build.json files
used for tests, so the language server could properly load those
test projects.
By default, couriser will use AdoptOpenJDK 8 to run the server, so we
needed to tell it to use jdk 21. Coursier will download the JDK if
necessary. It uses an index to figure out where to download it from:
https://get-coursier.io/docs/2.0.6/cli-java#jvm-index. The version of
coursier we are using in the extension has an old version of the index,
so we needed to provide an updated index for coursier to pull from.
Also, we needed to tell coursier specifically which jdk to use (not just
21), because by default it tries to use AdoptOpenJDK, when there's no
AdoptOpenJDK 21 (it is under the name Adoptium) now.

This is a temporary solution, meant to avoid downloading a second version
of coursier which had an updated index and could properly find the right
jdk to download. In the future, we will ship the language server as a
standalone executable, and can remove coursier altogether.

I also updated the tests to stop using timeouts, so we don't have to worry
about an inconsistent download time in CI.
@milesziemer milesziemer merged commit b381d23 into smithy-lang:main Aug 1, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants