Intelligent commands

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 #2898

• Add popup to explore the commands macro #2899

• Command’s goals #3256

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

• Add Command Palette #2901

• Better display when the commands are long in process panel #2911

• Add Command target definition #3501

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

• Save when command editor is closed #3497

• Sync command editor with workspace’s projects updates #3496

• Update command’s editor title when command name edited #3494

• UX improvements in the commands panel #3493

• Provide autocompletion for macros in command editor #3498

• Light theme compliance for command editor #3495

• Implement new toolbar for execution commands #3519

• Change schema data type for project attributes #3758

• Hide Zoom ruler and Overview ruler in command line and preview URL 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

[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

[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).