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

We should support a new JSON file ide-extra-tools.json (similar to ide-custom-tools.json) that allows to define additional installations. Example:

{
  "java": {
    "client": { "version":"11.0.27_6", "edition":"azul" },
    "process-engine": { "version":"21.*" }
  }
}

This would mean that we request two extra installations of Java:

1. One should be installed to $IDE_HOME/software/extra/java/client and point to version 11.0.27_6 of azul edition (currently not yet supported).
2. One should be installed to $IDE_HOME/software/extra/java/process-engine and have the latest version starting with 21. from the default edition (java which is technically temurin).

In the same way more tools like java can be configured in the same JSON.
Obviously only local tools are supported (and also this may only work fully functional with tools that support the software repo).

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 by EXTRA_«TOOL»_VERSION. The edition is configured by EXTRA_«TOOL»_EDITION but 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 like java or dotnet this can make sense and this is the typical use-case this story is about.