impl: support for Toolbox 2.6.3 #124
Conversation
Toolbox API is upgraded to 1.1.41749 which comes with new API additions and some deprecations. Kotlin stdlib was also increased to a newer patch version
The CustomRemoteEnvironmentState is deprecated, and replaced by a new class CustomRemoteEnvironmentStateV2 which now supports i18n state labels
Toolbox provides two callbacks, one before an SSH connection is established and another one which executes when the ssh connection is stopped. The latter was deprecated in the favor of a new callback that also provides hints on whether the user requested the disconnect.
Toolbox provides a callback for scenarios that involve the env. deletion. This allows plugins to react and clean the internal state. With the new TBX API, the delete callback API is deprecated in the favor of a mutable state flow, a reactive approach that allows consumers to observe and react to state changes over time.
The available API up to TBX 2.6.3 was buggy in terms of URI handling. It didn't allow plugins to programmatically install remote ides and launch them. The launch operation only worked when the IDE was already installed and a project was already opened with the IDE. TBX 2.6.3 adds a new API, _RemoteToolboxHelp_ which provides routines for listing the available IDEs on the remote, what is already installed and a command to install specific versions of the IDE. Additionally, there were fixes provided to the existing _ClientHelper_ which now launches the JBClient if a project was not specified. An additional quirk I've discovered is that if we provide a project, and that project was not already opened (present in the Projects tab) the IDE still won't open. And there is no API available to query the available projects. This commit uses the new API to: - query the installed ides - check if the provided ide is in the list of already installed IDEs. - if that's not the case we query the available list of IDEs and the available versions - if the provided ide and build no., is in the available list we will schedule it for install - if not, we select the latest available build number for the provided product code. - wait for the remote IDE to be installed - and then download and launch the JBClient with a project path if it was provided.
Refactored code around uri, token, workspace and rest client resolving by encapsulating code in clearly named methods. Rest client resolving was overly-complicated (code inherited from Gateway), with token being a mandatory parameter. Removed a lot of code that asked the token from the user if it was missing. Also, I decided to use a snackbar to show errors because of attached regression in TBX. A bottom simple dialog is more pleasing to the eye than a dialog in the middle of a page. https://youtrack.jetbrains.com/issue/TBX-14944/Pop-up-dialogs-are-only-displayed-on-the-main-envs-page
Refactored code around workspace and agent resolving.
Refactored code around cli initialization.
Refactored code around remote ide installation, local jbclient install and launch
Removed unused code and refactored unit tests to take into account that some of the methods are no longer static, and that return type changed.
Rename class to be in sync with the class it tests
`folder` URI param needs to be a path to an IDEA project that was already opened in the IDE. Or it should not be provided at all otherwise the remote IDE won't start.
Switched the order of the steps, the agent and hist state is resolved only after the workspace was resolved and after it was in a running state. Otherwise URI handling during workspace startup could provide misleading errors related to agent not existing or not being ready.
|
Test scenarios I've covered:
|
And only then start validating the parameters. Otherwise, we can end up in a situation where we ask TBX to show a snackbar while TBX is not yet visible/initialized. In that case the UI page doesn't show the snackbar
Toolbox already does that whe executing a URI while TBX is stopped. And during runtime it seems that snackbars have the ability to request the window to be visible. Only the rest of the dialogs need explicit request for the TBX window to be visible
This version is only supporting TBX 2.6.3 and above so it is worth at least a minor increase.
Toolbox 2.6.3 comes with a couple of new additions in the API which need the following changes:
finish support for URI handling. The available API up to TBX 2.6.3 was buggy in terms of URI handling. It didn't allow plugins to programmatically install remote ides and launch them. The launch operation only worked when the IDE was already installed and a project was already opened with the IDE.
TBX 2.6.3 adds a new API, RemoteToolboxHelp which provides routines for listing the available
IDEs on the remote, what is already installed and a command to install specific versions of the IDE.
Additionally, there were fixes provided to the existing ClientHelper which now launches the JBClient
if a project was not specified. An additional quirk I've discovered is that if we provide a project, and
that project was not already opened (present in the Projects tab) the IDE still won't open. And there
is no API available to query the available projects.
This PR uses the new API to:
use new environment state API. The CustomRemoteEnvironmentState is deprecated, and replaced by a new class CustomRemoteEnvironmentStateV2 which now supports i18n state labels
use the new ssh disconnect callback. Toolbox provides two callbacks, one before an SSH connection is established and another one which executes when the ssh connection is stopped. The latter was deprecated in the favor of a new callback that also provides hints on whether the user requested the disconnect.
use the new delete callback API. Toolbox provides a callback for scenarios that involve the env. deletion. This allows plugins to react and clean the internal state. With the new TBX API, the delete callback API is deprecated in the favor of a mutable state flow, a reactive approach that allows consumers to observe and react to state changes over time.