Incorporate use of Che CLI with profile capability

[TylerJewell]

First, we have always wanted to do a more enhanced Electron packaging - but we have been hard at work on improving the overall usability of the launcher, and unable to get to this point. So super pleased that you are able to do this work.

We have had a general vision of having the Electron client be the primary install for new individual developers. They would get the binary, install it, and then launch it. Within the Electron desktop application, there would be intelligence about whether the client was going to connect to a remote Che server (could be Che or a Codenvy). Or, would it be a local Che server. If it's a local Che server, there are a couple choices - start with default, or perhaps start from a profile. You could envision a really nice launcher screen that lets users the user choose one of these options.

To facilitate this - we have improved the Che CLI. I've added (still needs more testing) a che profile capability that lets users add / remove / list / set / unset profiles. You can set the name of the image, container, and any Che environment variable in a profile. And once a profile is set, then the Che CLI will load that profile to send to the launcher instead of using environment variables. If no profile is set, then environment variables will be used. This new capability is being tracked in this pull request: eclipse-che/che#2119.

[dtoebe]

Ok once I have the full basic functionality I will plan on incorporating the profiles functionality in a separate branch until it is fully functional in the stable branch of che

[dtoebe]

Per my plan on becoming an Eclipse project is it ok to have a codenvy button when the profiles window pops up? or will that violate any license with Eclipse?

Per your original view of the electron app, you guys got rid of the binary download for che and all local installs are through Docker only now right? And is Vagrant still and/or will continue to be an option?

[TylerJewell]

Yep, you are allowed to put vendor stuff into the product. It's the source code that has to be open source. But lots of open source products link to other vendor products in their product. For example, lots of products link to GitHub, but GitHub is a paid service and not open source. So this is no different.

On the type of installation - we make the public statement that Vagrant and Server methods are deprecated. But the reality is that we still have a Vagrant installation (it just launches a VM with Docker inside and then uses our Docker launcher). And we do also support pure server-based launches of the Che server for extension developers / plugin developers and che developers.

But the issue with vagrant / native launches of Che is that the syntax is slightly different on different operating systems. And the underlying dependencies of Vagrant / VirtualBox / Java / Maven are slightly different on each OS. So it got to be a challenge to support.

The new Docker launcher is common syntax on any OS and we have tested it heavily on a lot of different Docker configurations. It also follows good 12-form factor app design.

The other benefit of the new launcher is that nothing has to be installed - you can do a docker run eclipse/che syntax and it takes care to get the right binary image installed. So now you can silently start che servers anywhere you want.

[TylerJewell]

@dtoebe - we made a commit to the CLI and che-launcher today that should add in this new profile capability. You can see the specs on eclipse-che/che#2119.

[dtoebe]

Ok cool looks good. over the next couple day I will create a simple and detailed roadmap And I will email you with them once they are ready