Support for extra tool version #1298
Description
As a IDEasy user, I want the ability to have a second version of the same tool in my project so that I can run two different parts of my project with different version of that tool.
An example is Java where some projects may need a different version for the frontend than for the backend part because a migration is ongoing or one part is currently blocked from also upgrading to the newer java version.
As a workaround custom tools can be used but that requires to maintain a custom software repository and upload/provide all the tools there. For some vanilla tool already supported by IDEasy this overhead does not seem to make sense.
Solution
As a solution variables like EXTRA_«TOOL»_VERSION and potentially EXTRA_«TOOL»_EDITION should be supported.
If «tool» gets installed (ide install «tool») then we should check for EXTRA_«TOOL»_VERSION and if that is defined, do an extra handling:
- we create an extra installation to
$IDE_HOME/software/extra/«tool»configured byEXTRA_«TOOL»_VERSION. The edition is configured byEXTRA_«TOOL»_EDITIONbut if undefined falls back to the regular edition mechanism (``«TOOL»_EDITIONwith default of«tool»` and additional existing special excuses). This installation must not be added to `PATH` or `«TOOL»HOME` (maybe `EXTRA«TOOL»_HOME` would be a good idea). - if the resolved extra version and edition are identical to the regular one, we log a WARNING since then the extra tool will be identical to the regular tool and the log message should indicate that something is questionable.
- depending on the tool this feature may be disabled. E.g. for GraalVM this feature will not make sense since the default installation already resides in
extra. Further, for IDEs I also do not see the use-case to install 2 different versions in parallel. But especially for SDKs likejavaordotnetthis can make sense and this is the typical use-case this story is about.