You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have implemented a lot of cross-cutting logic for tool installations in ToolCommandlet.
However, we have tools like Docker that behave very differently: Those are tools that get installed globally, that is:
You can not have multiple installations of the same tool on the same computer at a time.
These tools are NOT installed into IDE_HOME/software but somewhere globally into the system (e.g. C:\ProgramFiles on Windows or /Applications on MacOS).
The downloads of such tools will never be extracted (see isExtract() method) and actually installInRepo does not really make sense here.
We should discuss and decide the following design options:
Make ToolCommandlet more generic, add a protected method isGlobalInstallation() that returns false by default that can be overridden by global commandlets like docker.
Create abstract sub-classes GlobalToolCommandlet and LocalToolCommandlet derived from ToolCommandlet and make all existing ToolCommandlets derive from LocalToolCommandlet. Then move logic like installInRepo method into LocalToolCommandlet and also for some other methods like install(...) but keep an abstract signature for the latter in ToolCommandlet. Then implement the install(...) methods in GlobalToolCommandlet.
The text was updated successfully, but these errors were encountered:
Once this story is implemented, we can discuss what global tools we could add to IDEasy:
git - actually we do not really require git-bash to be present to run our CLI that can also run directly from CMD without any bash being present (however some features like Add support for executing scripts #69 may not work). So we could also add the ability to install git via IDEasy so we download the latest installer and run it.
keepass (there is also a MacOs port and IMHO a linux variant)
subversion (TortoiseSVN on Windows?)
how about windows specific tools like Notepad++, SuperPutty/WinSCP/Kitty, ...
pre-requisites for native-image compilation with GraalVM (e.g. Visual Studio libs on Windows)
We have implemented a lot of cross-cutting logic for tool installations in
ToolCommandlet
.However, we have tools like
Docker
that behave very differently: Those are tools that get installed globally, that is:IDE_HOME/software
but somewhere globally into the system (e.g.C:\ProgramFiles
on Windows or/Applications
on MacOS).isExtract()
method) and actuallyinstallInRepo
does not really make sense here.We should discuss and decide the following design options:
ToolCommandlet
more generic, add aprotected
methodisGlobalInstallation()
that returnsfalse
by default that can be overridden by global commandlets likedocker
.GlobalToolCommandlet
andLocalToolCommandlet
derived fromToolCommandlet
and make all existingToolCommandlet
s derive fromLocalToolCommandlet
. Then move logic likeinstallInRepo
method intoLocalToolCommandlet
and also for some other methods likeinstall(...)
but keep an abstract signature for the latter inToolCommandlet
. Then implement theinstall(...)
methods inGlobalToolCommandlet
.The text was updated successfully, but these errors were encountered: