| Re: [che-dev] Java extension is getting bigger |
It is a different discussion. One is how we can mix and match different extensions in the same container, the other is how we can target different JDK versions. In particular, there are probably literally 100s of different versions of the JDK. In an ideal world, we would be able to target each one of them. On the other hand, we would ideally only have one version of the JDK to run jdt.ls on (because then we would only have to test the tooling on one runtime).
Of course, it all servers the same purpose in the end, but
technically, the two questions are very different.
/Thomas
It is not a different discussion ... sorry Thomas, I don't see how my comment is related to https://github.com/eclipse/che/issues/13250.We are talking about the best option to make available the quarkus extension to our end users. Some project(devfile) would use it, some others won't.
Sun Tan
Senior Software Engineer
Eclipse Che - CodeReady Workspaces @ Red Hat
Paris JUG leader
sutan@xxxxxxxxxx
M: +33621024173
On Fri, Nov 8, 2019 at 2:23 PM Thomas Mäder <tmader@xxxxxxxxxx> wrote:
On 08/11/2019 14:03, Sun Tan wrote:
> hello,
> I think we should go for #1, but how do we deal with memory ---> sum
> of all the memoryLimit defined in each individual container ?
We'll have to define some policy, but I leave that to the kube experts.
> If not #1, Could we have `flavosr` ? like we have `java8`, `java11` we
> could have `java8-quarkus` that would be a first simple option doable
> in few hours.
I think this is an entirely different discussion:
https://github.com/eclipse/che/issues/13250. Target and runtime of the
tooling should not be the same.
/Thomas