Avoid inheriting environment variables from other IDEasy project if switched in the same shell session

[hohwille]

Expected behavior

When I run ide in «project1» and then switch (cd) to «project2» and run ide there the result should be like if I would open a new shell immediately in «project2» and run ide.

Actual behavior

IMHO variables that had been set in «project1» but are not set in «project2» will shine through.
As a result variables such as JAVA_VERSION=8* from «project1» may impact «project2» if such variable is nowhere defined in «project2».

Hints

This is a tricky one as this is rather a generic design flaw than an implementation bug.
However, the IMHO best solution would be to consider inheritance from EnvironmentVariablesSystem (System.getenv) only for dedicated variables. Then things like «TOOL»_VERSION and «TOOL»_EDITION cannot be taken from environment variables from the outside world causing such problems.
Further if we go in this direction would could also mark better what variables should be made visible to ide env.
IMHO exposing «TOOL»_VERSION and «TOOL»_EDITION variables to the shell is "pointless pollution" rather than being really helpful. This all seems to come from the heritage of devonfw-ide and with IDEasy we have the chance to think such things further through. With bash we could only do very simple things while now we have reliable ways for advanced features that can help us to get more reliable and consistent results.
See also #235 in this regard.

[hohwille]

Some thoughts and ideas to make further process here:

• we could explicitly add logic to EnvironmentVariablesSystem that prevents resolving variables like *_VERSION or *_EDITION so these variables must come from ide.properties files and not from some shell env variable.
• In the same way in EnvironmentVariablesSystem we could check for values pointing to a different IDEasy project. So e.g. a variable that has a value starting with $IDE_ROOT followed by a different than the current project could be ignored. If this one is implemented, care for robustness to make it also work if outside of a project and not break anything because of NPE, etc.
• we have some logic (see #925: IDEasy cannot handle faulty JAVA_HOME definition #997) that implicit environment variables from «Commandlet».setEnvironment are not overridden if already defined. We could change this behaviour to always override variables like JAVA_HOME. The reason for this change was that if some developer decides to explicitly set JAVA_HOME in his ide.properties file that he may have a reason to do so and also takes responsibility for that variable definition so we should not ignore and override it. However, if an IDEasy project uses Java then JAVA_HOME should point to that version installation, shouldn't it? We could even consider checking if an existing JAVA_HOME comes from ide.properties or some env vars and make our choice dependent on that. As well we could check if the value of it is pointing to an existing directory and if not always consider it as broken and override it. IMHO we should go for KISS and override it regardless. Users should not define JAVA_HOME in ide.properties. I do not see the use-case... Point to a manually installed custom Java? If you want to do such hacks, then you can also manually switch the symlink...
• Finally, we must accept that the general problem described in this issue is really hard to solve. If a property is set e.g. FOO=bar how should we know in project B whether that property was set before in project A or it is set globally (e.g. in system env variables or bashrc)? This is only possible if we would create a backup of the users environment variables somehow when initializing IDEasy for the first time. So if the variable IDEASAY_ENV_BACKUP is undefined, we dump all env variables into that variable as JSON and export it. Else if the variable is set, we restore the variables from it in EnvironmentVariablesSystem. However, this is absolutely not KISS, there may be length limitations for env variables by the OS that we could hit, etc. I would say that average users just have one project setup with IDEasy. Users that have multiple projects will typically open a new terminal for each project and then all is already working perfect. Only if you switch between projects in the same "context" (shell, sub-process, etc.), this turns out to be an actual problem. So the main target audience may be the IDEasy development team that uses IDEasy to launch IntelliJ and inside that IntelliJ runs IDEasy from the Java code on a different project for testing specific scenarios. Therefore, we should not over-engineer IDEasy for such edge-cases. Some of the pragmatic and simple improvements discussed above are worth to consider implementing but such IDEASAY_ENV_BACKUP is not what I would suggest right now.

[jan-vcapgemini]

I can emphasize that this issue is more critical as my mvn clean install just installed my pom into the wrong project.
[INFO] Installing D:\projects\progressbar\workspaces\main\progressbar\pom.xml to D:\Projects\ideasy-dev\conf\mvn\repository\me\tongfei\progressbar\0.10.1\progressbar-0.10.1.pom