On Wed, 2019-07-10 at 11:56 +0200, Mario wrote: On Wed, 2019-07-10 at 11:21 +0200, Mario wrote: s2i is OpenShift only but we can find another mechanism to build images on Kubernetes.
However I would like to understand is if we really need to do a compilation at runtime. Because it would make workspaces startup slower and it should be worth it.
It would make workspace creation slower, not startup, and only if we don't have a caching mechanism for the build images.
What's the use case that we don't support currently that we will support if we do the compilation at runtime? In other words what are the benefits?
Mix and match jdt.ls extensions and basically any Java-based Che plugin that has a dynamic component
We can already run java-based che plugins on the same sidecar. Can you do an example of some feature that we don't support currently (or is hard to support) and that, as a Java developer, I would want in my workspace?
Yes, but we have to build a Che 7 plugin for every combination of jdtl.ls plugins. 3rd parties can make their own VS Code Extensions that extend the jdt.ls process.
What are the steps that would be needed to "native-compile jdt.ls" at runtime? Install a particular JDK? Copy some libs? Do a java compile from jdt.ls source code + some libs?
The idea is to run use Graalvm for this. What the concrete steps are: tbd.
Ok but we can use graalvm to build jdt.ls at build time. Why runtime? What are you going to do at runtime that you cannot do at build time?
jdt.ls is extensible. We need to know all extensions in order to build a native.
|
