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
582 stars 141 forks source link

Would it be possible to rewrite Xtend code in Java? #740

Closed mkoncek closed 1 year ago

mkoncek commented 1 year ago

I wanted to package https://github.com/eclipse/lemminx which depends on this library in Fedora. This library depends on xtend plugin, which itself depends on Tycho. Tycho depends on itself. This is all a dependency hell that could be simply avoided if this project got rid of the rather exotic language. Would this be possible?

jonahgraham commented 1 year ago

I believe our most recent release got rid of this dependency for the runtime components (see #494). If there are still some unnecessarily complicated dependencies can you be explicit about them. I.e. Which dependency in which bundle is causing problems

As for removing xtend source from LSP4J that is unlikely as we depend on the code generation facilities

mkoncek commented 1 year ago

No, I am talking about build dependencies. In Fedora everything has to be built from source and has to be properly packaged. Is there any other way around?

cdietrich commented 1 year ago

The Xtend gradle plugin does not depend on tycho So you want to build everything Eclipse emf 3party deps of Xtext and Xtend from scratch Then Xtext and Xtend from scratch Then the Xtend gradle plugin Then gson And then this lib?

mkoncek commented 1 year ago

I forgot to mention, in Fedora we don't have Gradle so all Java packages requiring Gradle are slightly modified to use Maven. This is usually done by fetching poms from Maven Central, sometimes editing them and sometimes adding a manually-written aggregator POM. So in this case I am interested in Xtend maven plugin. I haven't spent too much time on it, but it looked like I needed to build modules with packaging eclipse-plugin, for which Tycho is needed. Or are those not necessary for having a minimal functioning plugin?

cdietrich commented 1 year ago

Again Xtend uses Xtext and Xtext uses eclipse (e.g. eclipse.core.runtime, org.eclipse.jdt) and these are built using maven tycho too. I also don’t know how gson is built

jonahgraham commented 1 year ago

Can you generate the java files from the xtend files and contribute that as a patch to your build package? In the past we actually had the generated java files in our git repo.

mkoncek commented 1 year ago

I also don’t know how gson is built

Gson is not a problem, we have it.

Can you generate the java files from the xtend files and contribute that as a patch to your build package? In the past we actually had the generated java files in our git repo.

I was thinking about that, it looks like Xtend it almost identical to Java, but i don't know how to safely transpile the code.

cdietrich commented 1 year ago

You can’t The main reason we use Xtend is that Xtend has a feature called active annotations which generates a ton of boiler plate code

jonahgraham commented 1 year ago

I was thinking about that, it looks like Xtend it almost identical to Java, but i don't know how to safely transpile the code.

Do a gradle build normally and make a patch with the contents of the *-gen folders.

mkoncek commented 1 year ago

You can't patch-in code you generated elsewhere...

cdietrich commented 1 year ago

Wonder how fedora builds other eclipse stuff eg https://packages.fedoraproject.org/pkgs/eclipse/eclipse-jdt/fedora-34.html#files

jonahgraham commented 1 year ago

PS the sources bundles in Maven have the java files in them - e.g. https://repo1.maven.org/maven2/org/eclipse/lsp4j/org.eclipse.lsp4j/0.21.0/org.eclipse.lsp4j-0.21.0-sources.jar

mkoncek commented 1 year ago

1) We don't have much Eclipse in Fedora anymore 2) sources .jar looks interesting but will need to be discussed. Point of source code being "The preferred way of modification". 3) We went as far as to having bootstrapped Maven.

szarnekow commented 1 year ago

Can you help me understand why you build everything from source? I'd expect the resulting Jar files to produce different checksums than the released bits on Maven Central would produce. The signing information would be different, too. What is the goal of that exercise?

mkoncek commented 1 year ago

That is the Fedora policy, we build everything from source so that we can patch it. We package Java libraries only if they are dependencies of applications or otherwise needed for the distribution. We use a modified maven during the build which ignores the versions and only uses .jars from the system. Packages can often be stripped of some functionality that is not relevant for packaging purposes or due to missing dependencies. Plus we try to debundle any statically linked or otherwise bundled dependencies. This approach is only relevant when building Fedora packages, not when a regular user develops their own SW using maven.

So, if I want to add XML language server, all its dependencies must be available as Fedora packages. I looked into Tyxho and we did use to have it in Fedora (but was orphaned later). Nevertheless the package looks complex https://src.fedoraproject.org/rpms/tycho/blob/f34/f/tycho.spec.

So, I need a minimal dependency chain which leads to having successfully compiled XML language server.

What exactly does Xtend give you that isn't present in Java?

szarnekow commented 1 year ago

LSP4J uses https://www.eclipse.org/xtend/documentation/204_activeannotations.html to generate code from Java interfaces. This greatly reduces the maintenance effort and guarantees consistency within the code base. It would be possible to use different code generation techniques, but it'd require a major rewrite which is out-of-scope for the time being. See the first response in this thread:

As for removing xtend source from LSP4J that is unlikely as we depend on the code generation facilities

mkoncek commented 1 year ago

After attempting several more builds I came to a conclusion that if we want XML-LS in Fedora, we would have to revive a lot of Eclipse packages going as far as to Eclipse JDT which is possible but someone would have to maintain it.

As for the original question, the answer is clearly "no".