Upgrade Jakarta websocket from 2.0.0 to 2.1.0

eclipse-lsp4j / lsp4j

A Java implementation of the language server protocol intended to be consumed by tools and language servers implemented in Java.

https://eclipse.org/lsp4j

Other

613 stars 145 forks source link

Upgrade Jakarta websocket from 2.0.0 to 2.1.0 #661

Closed apupier closed 8 months ago

apupier commented 2 years ago

it allows to be compatible with latest Tyrus RFC implementation 2.1.0 see https://jakarta.ee/specifications/websocket/2.1/ and https://github.com/eclipse-ee4j/tyrus/releases/tag/2.1.0 Note:

wasn't able to build the project (do not have anymore a working gradle environment locally and not familiar with Gradle) so wasn't able to try everything locally
i was able to force usage of this newer websocket api in my own project and my tests using Tyrus 2.1 are passing fine, see https://github.com/camel-tooling/camel-language-server/pull/799

eclipse-lsp4j-bot commented 2 years ago

Can one of the admins verify this patch?

cdietrich commented 2 years ago

How is the orbit side of this gonna be addressed https://github.com/eclipse/lsp4j/blob/main/releng/releng-target/lsp4j.target.target

HannesWell commented 1 year ago

I would like to suggest to replace InstallableUnit-Location that contains Jakarta websocket, guava and gson with a corresponding Maven target.

This would allow you to fetch those artifacts from Maven Central without the need to maintain/wait for Orbit. If you agree I can create a PR.

cdietrich commented 1 year ago

we might to do https://github.com/eclipse/lsp4j/pull/529 first. this gets rid of guava as runtime dependency (needed as compile dep only)

jonahgraham commented 1 year ago

I am quite keen on what @merks has been working on in https://download.eclipse.org/oomph/simrel-maven/ too.

HannesWell commented 1 year ago

As you prefer, both sounds good. Nevertheless I expect the change a Maven target to be a simple local Change in the target File. It would have the Advantage that it can be done now.

And one glory day we maybe even get automated Updates via dependabot: https://github.com/dependabot/dependabot-core/issues/4682

If you later still prefer a Single Location for 3ed Party deps, switching to Ed's solution should be easy too. I think that it is a valid and good solution, but Maven Targets+dependabot would probably be more Direct.

jonahgraham commented 1 year ago

Ok. If that works we'll take it. I have no objection to the maven in target, but it needs pgp setup too for the project and may need tycho version bump too.

jonahgraham commented 9 months ago

We now consume the latest jakarta websocket version from Orbit - see #791

This change is sort of orthogonal as it sets the minimum version. Should we make the minimum 2.1.1 as that is the version we get from Orbit, and the latest version on Maven Central (its the same jar in both places BTW - its just that Orbit makes it nicely into a p2 site)

jonahgraham commented 8 months ago

I don't think we need to change the minimum version as I don't think we have requirements on newer version. If needed, please rebase the commit and reopen.