Re: [che-dev] Custom builds and side cars

[Mario <mario.loriedo@xxxxxxxxx>]

Sun having 2 distinct containers doesn't mean not being consistent. We can still update the default Java stack to to have the same versions of the JDK in both the LS and the user runtime/builder image. 

But we should encourage users to user their own CI and prod images in their Che workspaces. And discourage them to patch/replace their images to host our Java/Go/Python LS. We should make it possible to replace the container that host the LS but we should make it clear that the default should be to use that is in the che registry. And if we are not going to do it users won't do it neither.

Something that we need to improve to make this more straight forward is to have multiple remote-plugin-runner-java images for different versions of the JDK and having different versions of the plugin in the che-plugin-registry. In other words today we have

che-plugin-registry/plugins/org.eclipse.che.vscode-redhat.java/

                                                  |

                                                  '--- 0.38.0/

but I think we should have instead

che-plugin-registry/plugins/org.eclipse.che.vscode-redhat.java/

                                                  |

                                                  '--- 0.38.0-openjdk8/

                                                  '--- 0.38.0-openjdk11/

                                                  '--- 0.38.0-openjdk12/

Last week Thomas started a thread about plugins versioning and specifically how to distinguish 2 plugins whith the same vs code extension version level but using different containers and that's a good use case.

On Wed, Apr 3, 2019 at 3:32 PM Sun Tan <sutan@xxxxxxxxxx> wrote:

I don't think the story about go c/c++ is the same as the story with maven/gradle and jdt.ls,
For the mavne/java story, a theia-plugin or a command line tool should be at the same level. These are both user interface. If the user would like to use another version, it is his choice to fork/duplication/customize but what we deliver should be consistent. I cannot imagine doing a mvn dependency:list in theia and not having the same result doing it on the command line because it is using different versions of maven. Same for error message and so on.
We offer to the user a very powerful way to customize his tools but we need to be consistent in what we deliver. My 2 cents :)

Sun TAN
Senior Java Software Engineer
Eclipse Che - Openshift.io @ Red Hat
Paris JUG team member

Mobile : +33 6 21 02 41 73
Email : sutan@xxxxxxxxxx 
Email Paris JUG : sunix@xxxxxxxxxxxx
Blog: http://blog.sunix.org
twitter: @sunsengdavidtan 

----------------------------

On Tue, Mar 26, 2019 at 5:06 AM Yevhen Ivantsov <yivantso@xxxxxxxxxx> wrote:

Not only builder images. Debugger first builds and then runs. So, I just press Debug, and I need certain packages in a plugin container.

On Tue, Mar 26, 2019, 03:50 Gorkem Ercan <gorkem.ercan@xxxxxxxxx> wrote:

I feel that we are now talking about builder images. These are images that contains all the tools for building a project

and used by CI to build the containers asa well as other binaries. With more CI builds being done natively on kubernetes, these 

sort of builder images are more common. I wonder if a better approach for Che is to recognize that they exists and 

take advantage of them and perhaps assist on their creation?

--

Gorkem

On Mon, Mar 25, 2019 at 11:15 AM Mario <mario.loriedo@xxxxxxxxx> wrote:

Let me attach the diagram that I have shared with some of you before. These are the Java Stacks. Go, python, nodejs, C# and PHP.

The important thing to notice, and the difference with the past, is that we are not going to maintain the runtime containers anymore. As you see there are 4 Java stacks in the diagram but only the runtime container changes and those are the official images maintained by maven, gradle, tomcat and postgresql teams respectively. 

On Mon, Mar 25, 2019 at 1:04 PM Mario <mario.loriedo@xxxxxxxxx> wrote:

installs gcc and g++, because "it is not uncommon for a go build to depend on gcc and g++"

We had the same problem for the new Java stack: mvn is not installed in the JDT LS sidecar. The decision in that case has been to use a dedicated runtime container (based on the official maven image, gradle image etc...). The user is not supposed to open a terminal in the JDT LS sidecar but to open it in runtime container. The workspaces commands will be run against the runtime container as well.

The Java stack solution is not ideal because: 1) the jdk versions of the runtime and the sidecar may not match leading to some inconsistencies 2) we need to start 2 containers and that means more resources + longer startup time.

 

But Eugene PR's solution is not ideal neither because 1) as Thomas said users will need to build and distribute their own sidecars 2) the main ws.next promise was to let user reuse their runtimes and we are not respecting it 

So even if the Java stack solution is not perfect it's currently the best trade-off we can propose.

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev