Do not require o.e.xtend.lib

[akurtakov]

It's not actually used thus only causes couple more bundles ending in the product for nothing.

[rgrunber]

Maybe it was our intention to support the compilation of the xtend language but never go around to doing it ? I don't see us having used this.

[rgrunber]

From another language server that's pure Java.

[INFO] +- org.eclipse.lsp4j:org.eclipse.lsp4j:jar:0.14.0:compile
[INFO] |  \- org.eclipse.lsp4j:org.eclipse.lsp4j.generator:jar:0.14.0:compile
[INFO] |     \- org.eclipse.xtend:org.eclipse.xtend.lib:jar:2.16.0.M1:compile
[INFO] |        +- org.eclipse.xtext:org.eclipse.xtext.xbase.lib:jar:2.16.0.M1:compile
[INFO] |        \- org.eclipse.xtend:org.eclipse.xtend.lib.macro:jar:2.16.0.M1:compile
[INFO] +- org.eclipse.lsp4j:org.eclipse.lsp4j.jsonrpc:jar:0.14.0:compile

lsp4j depends on lsp4j-generator which brings in xtend according to the pom file metadata, https://repo1.maven.org/maven2/org/eclipse/lsp4j/org.eclipse.lsp4j/0.19.0/org.eclipse.lsp4j-0.19.0.pom . This isn't expressed on the OSGi metadata though.

[akurtakov]

Does it mean that this change is effectively no-op as it keeps being transitively installed as a dependency? If that's the case feel free to merge or abandon as you see fit.

[rgrunber]

Well, this change will remove xtend from the product, but only because lsp4j doesn't have a dependency to lsp4j-generator in OSGi. However in the pom files, this dependency exists (compile-time). I'm just not sure why one has it, and not the other. Maybe it is only a compile-time dep and can be safely left out at runtime ?

@jonahgraham , would you know if lsp4j-generator is only needed at compile-time and safe to remove from runtime ? If so that would probably imply we could remove xtend.lib.

[jonahgraham]

AFAIU lsp4j-generator is only needed at compile time. @cdietrich has been working on removing xtend.lib at runtime, but for now it is still needed. Follow progress on that in eclipse-lsp4j/lsp4j#529

It may be the pom.xml is missing xbase from its dependency list (or relying on getting it transitively). The MANIFEST.MF for org.eclipse.lsp4j has an import package for org.eclipse.xtext.xbase.lib

[mickaelistria]

Does it mean that this change is effectively no-op as it keeps being transitively installed as a dependency?

It's not really a no-op from dep management perspective. Removing direct the OSGi requirement wire from org.eclipse.jdt.ls.core to org.eclipse.xtend.lib is a small optimization and simplification; it probably won't change much per se, but it's still a win.

[rgrunber]

@jonahgraham , just to clarify, if all we're using is org.eclipse.lsp4j & org.eclipse.lsp4j.jsonrpc (say 0.12.0, but eventually 0.19.0), is there any reason for us to keep a dependency to org.eclipse.xtend.lib ? As far as I can tell, neither the above lsp4j jars use xtend.lib. The language server seems to respond to requests without any issues/failures when it's left out of the runtime, and even jdeps doesn't show any imports to it.

Even a simple p2 installation leaves xtend.lib out :

$ p2iu https://download.eclipse.org/lsp4j/updates/releases/0.12.0/,https://download.eclipse.org/releases/2022-06 org.eclipse.lsp4j.jsonrpc/0.12.0.v20210402-1305,org.eclipse.lsp4j/0.12.0.v20210402-1305
Installing org.eclipse.lsp4j.jsonrpc 0.12.0.v20210402-1305.
Installing org.eclipse.lsp4j 0.12.0.v20210402-1305.
Operation completed in 8756 ms.
$ ls -1
com.google.gson_2.8.9.v20220111-1409.jar
com.google.guava_30.1.0.v20210127-2300.jar
org.eclipse.lsp4j_0.12.0.v20210402-1305.jar
org.eclipse.lsp4j.jsonrpc_0.12.0.v20210402-1305.jar
org.eclipse.xtext.xbase.lib_2.27.0.v20220530-0353.jar

[jonahgraham]

I think I am in a muddle between xtend.lib and xbase.lib. Both are needed for the generator, but at runtime it is just xbase.lib that is needed. Further to that it seems that xbase.lib dependency may not be properly reported in the pom dependencies (it is correct in the OSGi deps). And Christian is working on removing the dependency to xbase.lib in eclipse-lsp4j/lsp4j#529

[rgrunber]

Seems like this change is valid after all. CC'ing @testforstephen for awareness in case some other language server depending on JDT-LS may take advantage of this, but we really should aim to keep JDT-LS as slim as possible. @akurtakov , I would also remove the xtend.lib references in :

https://github.com/eclipse/eclipse.jdt.ls/blob/3c0e575630d2f7fd197bd57d093cb1328e174f9a/launch/jdt.ls.remote.server.launch#L109-L110

https://github.com/eclipse/eclipse.jdt.ls/blob/3c0e575630d2f7fd197bd57d093cb1328e174f9a/launch/jdt.ls.socket-stream.launch#L110-L111

https://github.com/eclipse/eclipse.jdt.ls/blob/3c0e575630d2f7fd197bd57d093cb1328e174f9a/launch/jdt.ls.socket-stream.syntaxserver.launch#L95-L96

https://github.com/eclipse/eclipse.jdt.ls/blob/3c0e575630d2f7fd197bd57d093cb1328e174f9a/org.eclipse.jdt.ls.tests.syntaxserver/META-INF/MANIFEST.MF#L23

https://github.com/eclipse/eclipse.jdt.ls/blob/3c0e575630d2f7fd197bd57d093cb1328e174f9a/org.eclipse.jdt.ls.tests/META-INF/MANIFEST.MF#L28

[akurtakov]

Seems like this change is valid after all. CC'ing @testforstephen for awareness in case some other language server depending on JDT-LS may take advantage of this, but we really should aim to keep JDT-LS as slim as possible. @akurtakov , I would also remove the xtend.lib references in :

https://github.com/eclipse/eclipse.jdt.ls/blob/3c0e575630d2f7fd197bd57d093cb1328e174f9a/launch/jdt.ls.remote.server.launch#L109-L110

https://github.com/eclipse/eclipse.jdt.ls/blob/3c0e575630d2f7fd197bd57d093cb1328e174f9a/launch/jdt.ls.socket-stream.launch#L110-L111

https://github.com/eclipse/eclipse.jdt.ls/blob/3c0e575630d2f7fd197bd57d093cb1328e174f9a/launch/jdt.ls.socket-stream.syntaxserver.launch#L95-L96

https://github.com/eclipse/eclipse.jdt.ls/blob/3c0e575630d2f7fd197bd57d093cb1328e174f9a/org.eclipse.jdt.ls.tests.syntaxserver/META-INF/MANIFEST.MF#L23

https://github.com/eclipse/eclipse.jdt.ls/blob/3c0e575630d2f7fd197bd57d093cb1328e174f9a/org.eclipse.jdt.ls.tests/META-INF/MANIFEST.MF#L28

All requested changes done.

[testforstephen]

CC'ing @testforstephen for awareness in case some other language server depending on JDT-LS may take advantage of this

Had a search in java extensions we owned, we didn't explicitly use this lib. Feel free to merge.

[cdietrich]

i am reviving my patch
my current working state is
https://ci.eclipse.org/lsp4j/job/lsp4j-multi-build/job/cd_toStringBuilder/lastSuccessfulBuild/artifact/build/maven-repository/
https://ci.eclipse.org/lsp4j/job/lsp4j-multi-build/job/cd_toStringBuilder/lastSuccessfulBuild/artifact/build/p2-repository/
this should drop all xbase and xtend + guava deps + lsp4j.generator

would be nice to get some feedback
see also

eclipse-lsp4j/lsp4j#529