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

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

Closed
mkoncek opened this issue Jun 8, 2023 · 17 comments
Closed

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

mkoncek opened this issue Jun 8, 2023 · 17 comments

Comments

@mkoncek
Copy link

mkoncek commented Jun 8, 2023

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
Copy link
Contributor

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
Copy link
Author

mkoncek commented Jun 8, 2023

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
Copy link
Contributor

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
Copy link
Author

mkoncek commented Jun 8, 2023

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Author

mkoncek commented Jun 8, 2023

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Author

mkoncek commented Jun 8, 2023

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

@cdietrich
Copy link
Contributor

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

@jonahgraham
Copy link
Contributor

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
Copy link
Author

mkoncek commented Jun 8, 2023

  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
Copy link

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
Copy link
Author

mkoncek commented Jun 9, 2023

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
Copy link

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
Copy link
Author

mkoncek commented Jun 9, 2023

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".

@mkoncek mkoncek closed this as completed Jun 9, 2023
@mkoncek mkoncek closed this as not planned Won't fix, can't repro, duplicate, stale Jun 9, 2023
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

No branches or pull requests

4 participants