Intelligent commands

[slemeur]

Goals

Eclipse Che commands are proposing a very high level of configurability, but in certain use cases, the navigation and access to the right command is difficult and user might run into commands which will not be executed properly.
With the new capabilities around multi-machine in workspace, the commands should also target the correct machine.

Commands are tied to a context which define in which situation they might be used. Intelligent commands are providing contextualized command definition and ability for the system to know when a command is appropriate or not.

Sub-Tasks

This section is providing the state of the implementation of the following specification. It also provides the list of all sub-tasks linked to it:

• Command Explorer + Command Editor Command Explorer + Command Editor #2898

• Add popup to explore the commands macro Add popup to explore the command macros from the IDE #2899

• Command's goals Commands' goals #3256

• Implement possibility to execute commands with a right-click from the explorer Implement possibility to execute commands from the context menu #2900

• Add Command Palette Commands Palette #2901

• Better display when the commands are long in process panel Better handle "Process Panel" when commands are long #2911

• Add Command target definition Add ability to manage commands' targets #3501

• Add abillity to try a command from the command's editor Add ability to try a command #3502

• Save when command editor is closed Ask user to save the command modifications on closing editor #3497

• Sync command editor with workspace's projects updates Projects table in command editor should be updated when projects are changed #3496

• Update command's editor title when command name edited The title of the command editor tab isn't updated after changing command's name and saving it #3494

• UX improvements in the commands panel Position of create/remove/duplicate buttons aren't correct when Commands Explorer width is too small #3493

• Provide autocompletion for macros in command editor Add autocomplete for macros in command line and preview URL editors #3498

• Light theme compliance for command editor Command editor styles should respect IDE's light theme #3495

• Implement new toolbar for execution commands New toolbar for execution of commands and access to preview #3519

• Change schema data type for project attributes Change schema data type for project attributes #3758

• Hide Zoom ruler and Overview ruler in command line and preview URL editors Add ability to set different settings for different text editors #3779

Values

• Clearer and simpler way for user to find the default commands to build, test and run projects in a workspace.
• Better configurability options for commands
• Less error prone flow when executing commands

Commands's context

To run properly a command needs to be executed with the right context. Commands could be:

• Associated to a specific project of the workspace,
• Executed to a only a specific set of machines used in the workspace’s environment,
• Executed only if a certain set of dependencies are installed in the machine.

So the command’s context is defined by the following meta-datas:

Projects	Machines	Dependencies
The projects in the workspace where the command can be applied	The targets in the environment where the command will be executed	The dependencies or pre-requisites on machine which will allow the command to be properly executed
mvn clean install can be executed only across a Maven project	mvn clean install would be executed against a certain set of machine.	mvn clean install would run properly, only if Maven is properly installed in the machine.

To know its context, the command will have new settings options.

1- A command will know on which machine(s) it can be executed

Phase1:

• User will have the possibility to specify the machine(s) where the command can be executed. It is the definition of the base machines for the command.

Phase2:

• We add the notion of tag to commands. This notion allow to default the behavior of commands and enable it only for certain machines.
• For example:
  • mvn clean install would have the following tags: Maven, Java
  • Workspace machineAA would have the tags from the stack used: Maven, Java
  • System will be able to propose to execute mvn clean install onto machineAA

2- A command will know on which project it has to be applied

The command will have meta-datas to let the system know for which projects it can be applied.

If those meta-datas are not defined, it means the command is not project-specific and available in all project context.

For example:

• mvn clean install will be available only for specified maven project
• run script.sql will be available at any time

3- A command use macros in its definition to be apply to an IDE context (currently existing)

In a single workspace, the user might have multiple Maven projects.

Workspace:

• ProjectA
• ProjectB
• ProjectC

It is possible to define a command which will just be executed across the currently selected project (in the IDE project explorer). In this case the command definition will use the macros that we already have into the system:https://eclipse-che.readme.io/docs/commands#macros

Command definition
cd ./projects/${explorer.current.file.relpath}/ mvn clean install

4- A command could have a set of pre-conditions defined ?

There could be the possibility to define pre-check conditions in order to execute a command. This could be a script.

For example: before executing a mvn clean install command, the user will be able to configure the pre-conditions to check if the command can be executed.

• Check mvn installed: mvn -version
• Check java installed

Command’s goal:

When a user is configuring a commands, he is always doing it for a certain purpose, a certain goal or a certain phase of the project lifecycle. For example, he will define a command to “Build” the projects in the workspaces, he will define a command to “Run” a project, he will define a command to “Deploy” the project and so on.

Considering this notion of goal for a command, we will use them in order to better contextualize the commands:

• Build
• Test
• Run
• Deploy

Che will provide default set of goals, but user would have the ability to define/configure them

Command’s goal allow to configure default workspace commands and provide clearer organization and navigation into the commands.

Associated features

• “F5” keyboard shorcut would be always bind to a default command which will build+run the project
• Commands Panel:
  Panel displayed with keyboard shortcut which allow to browse and start any configured command.
• Primary vs secondary command configuration
  Ability to select the command used by default “build button” and “run button”
• Command Organization
  To regroup commands together, the user will have to give them a name and use slash (/) in the name of the command and we will treat these as a group separator.
  For examples, two commands named Maven/Clean-Install and Maven/Package will be grouped together into a submenu named Maven

Mockups (design not final)

Toolbar

Palette

Right Click actions

Command Explorer - Info

Command Explorer - Arguments

Command Explorer - Arguments - Macros Catalog

Command Explorer - Preview URL

Command Explorer - Common

[kaloyan-raev]

Nice concept!

I miss a "Configure" goal for commands.

Most of the time new projects are created by cloning a Git repo. I find myself creating commands for configuring the projects after their creation. Things like:

• setting write permissions for some folder
• generating sample data
• clearing some cache

[TylerJewell]

Thanks for the inputs.

We have a different concept in mind for the configuration of projects called a workspace template. Think of it containing all of the configuration that must be completed for a workspace to start, but the configuration items may vary by the person starting the workspace. For example, your workspace may need ssh keys to clone a project but the keys to be provided are personal to the person who creates the workspace.

We would create a nice guided workflow that has users fill in the dependencies of a workspace template upon workspace creation. I think all of those configuration items would happen here.

[gazarenkov]

Nice but I'd say there are some overall problem overthinking and overusing the Command as a first class entity

IMO it is more useful to make context dependent IDE Actions (menu item, toolbar button, context menu for project tree, context menu for particular position inside opened file etc). That would bring alot of services for developers with zero or small experience with particular technology but also experienced developers for scratching some things on very start of a project. While command related UX can duplicated this but primarily would be for more complex things to run.
We already have flexible Actions framework inside IDE and the context for displaying such an actions can be anything related to IDE Context state (project type, cursor position, content of file etc)
For Project dependent commands - I'd better make them Project Type dependent, physically it could mean storing them as attributes of Project Type, this way it is agnostic on whether the project was created from template or not.

If we need ability to assign commands to particular machine or even have some "smart" mechanism for recognizing command compatibility (mentioned as dependency), we need really strong vision about how to implement some semantic relationships between workspace/environment definition and software installed on machine runtimes. Otherwise it will be working for only limited cases (like it will work for perfectly written template but will not when something changed there).

[slemeur]

Thanks for your inputs @gazarenkov.

I think the ability to provide contextualized IDE Actions is a good idea. I know you always had that in mind. The only issue I see with that, is how a user would be able to customize the Actions (ie: command executed behind an Action)?

About "Project dependent commands" could be associated with Project Type - yes indeed. I agree with that.
I even think that the commands should be provided with Agents. If the user is enabling certain Agents in the workspace - it will also make available a certain set of associated and pre-configured commands.
For example: If user enables the MySQL Agent, it brings a set of commands to execute sql files.

How to recognize the command compatibility:
I believe there are two approaches for that:

• We could create a mecanism with tags association. Both commands and machines would have tags (inherited from stack definition, or enabled Agents). Commands could be executed only if tags are matching.
• We could have a "pre-check" section associated with a command definition. This "pre-check" would be a script which would allow to know if the command can be executed. For example checking mvn -version result before triggering any "mvn" command.

At first, we need to extend the configurability options for commands and improve the associated UI and UX.
In second time, we'll be able to pre-configure commands for the pre-configured stacks and templates. Then we can extend capabilities with Project Type + Agents and hopefully IDE Actions.

[gazarenkov]

No way to extend the Actions. They do what is logical for concrete context and do it nicely, with dedicated UX.
You can modify/add commands for the special cases instead.
It is two different things.

Agents...
I would keep them as simple as possible - just installation and running something specific but not limit something come from the image/recipe.
If I have MySQL provided with standard image, w/o Agent nothing should prevent me to call mySQL related commands/scripts.

Recognize command compatibility:

• tags are not reliable, this relies on particular mechanism of workspace creation (same example as for Agents below) - so if only for demo
• pre-check... well, I think for both "mvn -version" and "mvn install" you'll get the same - something like "mvn not found", so why to do this extra step

[benoitf]

• If I add Maven to my project I expect to see some basic commands for Maven
  like mvn clean install, having nice UI for configuring maven commands (not a to skip tests, work offline, etc.
• If I have a Java TestNG or Junit dependency in my project, I expect to have commands to run a dedicated test method, or the whole class or tests at package level or project level.
• I'm also expecting that I could use any remote tool (like a CLI to execute the default build command specified in the current project : like maven clean install with skipTests and offline mode)

about agents :

If I have MySQL provided with standard image, w/o Agent nothing should prevent me to call mySQL related commands/scripts.

Eclipse Che could propose me to add some MySQL facets/tools by seeing that my image contains MySQL as well (and I could have some UI about MySQL for running scripts into my machine)

In the same way I expect that an IDE propose me to select the type of the project (or facets, builders, etc) I would also expect that it could check what is my runtime and propose tools matching this runtime.
If I have tomcat installed in the machine, maybe it could propose me to add the stop/start command for tomcat as well.

[gazarenkov]

Yes, all of this can be implemented with IDE plugins

[TylerJewell]

This should all be server-side, however. Maven as a plug-in is not bound to the IDE - only actions should be. So the maven-specific part of the command is managed as a set of server-side activities. But then in the IDE, there could be a maven IDE Plugin that introduces an action or a widget that is bound to the server-side plugin. The context of the client would be passed as an input into the server-side command.

[slemeur]

Added Sub-tasks section

• link Better handle "Process Panel" when commands are long #2911